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ABSTRACT 


The Computer On-Line Police System (COPS) is a vehicle registration and ticket 
management system used at the Naval Postgraduate School (NPS) Security Department, 
which was designed by the Naval Computer and Telecommunications Station, San Diego, 
in 1991. COPS is an inadequate information system (IS) possessing the following 
weaknesses: severely limited query capabilities, outdated system hardware, software design 
errors, functionality gaps, antiquated graphical user interfaces (GUI), and no computerized 
data archiving capability. This thesis will try to alleviate these deficiencies. Using the 
System Development Methodology (SDM), the authors hope to provide NPS, and potentially 
other Department of Defense (DoD) security forces, with a significantly improved vehicle 
registration database system. 

A Baseline Assessment of COPS verified that a new IS was necessary. A new IS, 
called the Law Enforcement and Vehicle Registration Administration System (LEVRAS), 
was designed, programmed, and developed. The fully operational LEVRAS met all of the 
requirement specifications, and replaced COPS after a parallel conversion was conducted. 
Users were trained, and the NPS Security Department accepted the new database system for 
its daily operations. Fully supporting the LEVRAS lifecycle, maintainance will be 
performed by the NPS Management Information System (MIS) Department. 
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I. INTRODUCTION 


A. OBJECTIVE 


This thesis reviews the existing Naval Postgraduate School (NPS) vehicle registration 
system. It also designs, develops, and implements a new computerized administrative 
system supported by a relational database. The existing system is used for vehicle 
registration management and traffic ticket processing. The system is inadequate due to the 
following weaknesses: severely limited query capabilities, outdated system hardware, 
software design errors and functionality gaps, antiquated graphical user interfaces (GUI), 
and lengthy computer processing time. Our new system improves upon or eliminates the 
deficiencies identified above. It also includes anti-viral protection, minimizes data entry 


errors, and provides for system back-ups. 
B. BACKGROUND 


In October 1993, students living in Naval family quarters (La Mesa Village) at NPS, 
Monterey, California, were concerned over alleged child abduction attempts made in the 
housing area by a woman in a tan colored van. The vehicle was identified as having an 
official Department of Defense (DoD) Registered Vehicle Sticker, along with a red enlisted 
sticker (possibly issued by Fort Ord) on the front left corner of the windshield. Two 


numbers from a Texas license plate were also identified by La Mesa residents and reported 


to NPS Security. NPS detectives, in turn, contacted the NPS Vehicle Identification and 
Registration Office (VIRO) and Fort Ord Security, and requested a list of tan colored vans 
with Texas license plates and registered to military enlisted members. 

Neither the NPS VIRO nor Fort Ord Security could perform this simple task in a 
timely manner, because every enlisted vehicle registration card had to be checked by hand. 
The computerized information system used to store vehicular information was ineffective 


and unable to perform the requested query. Thus, the search for time-sensitive critical 








vehicle registration information came to a virtual standstill. After a week of manually 
sorting through NPS and Fort Ord vehicle registration cards, the target vehicle registration 
card still had not been located. 

In the meantime, NPS Security had received another report of a.child abduction 
attempt. Residents of La Mesa Village were deeply troubled by the slow security force 
response. The vehicle was still at large due to the ineffective query_process in these security 
database systems. Finally, after a three week intensive search, Fort Ord's database 
administrators found the registration card that matched the description of the vehicle. This 
thesis will attempt to substantially improve the ability of NPS police to respond when 
_ dealing with database queries and should bring peace-of-mind to the residents of La Mesa 


Village. 
C. SCOPE 


This thesis focuses on the comparison of the current NPS VIRO system, the 
Computer On-Line Police System (COPS), with a proposed alternative system, the Law 
Enforcement and Vehicle Registration Administration System (LEVRAS). The authors feel 
confident that the proposed system, LEVRAS, will be a vast improvement over COPS. We 
envision NPS and other military commands using LEVRAS as a standardized base/post 
vehicle management system via the DoD's Corporate Information Management (CIM) 
initiative. 

Two basic administrative functions of NPS Security are vehicle and traffic ticket 
management. The VIRO handles incoming personnel and contractor vehicle registration for 
database entry, and vehicle decal or temporary pass issue. All vehicle management 
functions are conducted within building 211. Ticket management includes the disposition 
and processing of traffic tickets, which is conducted in building 200. The main functions 
of ticket processing include input of traffic ticket data, correlation of ticket data to the 
individual, and point violation assignment for traffic violation infractions (after adjudication 
at traffic court). 











Supervisory reports from VIRO and the ticket management office are required on a 
"demand pull", as well as a routine basis. Weekly reports list ticket violations and decal 
issue and expiration from predominately newly reporting and graduating NPS students. Ad 
hoc reports are generated for Security Officer supervisory decision making and for NPS 
detectives criminal investigation work. 

Intra-networking between buildings 200 and 211 includes information exchange via 
hardcopy paper and walking 5.25 inch floppy diskettes between the buildings. To streamline 
this process, the authors suggested that a local area network (LAN ) be installed between the 
two respective workstations. This suggestion produced a work request generated by Mr. 
Gregg Caughran, NPS Security Officer, and was approved expeditiously. The LAN, along 
with the authors’ new database administration system, will be developed and installed 


concurrently by management information system (MIS) contractors and the authors, 


respectively. 
D. METHODOLOGY 


A COPS Baseline Assessment will determine the existing architecture of COPS in 
terms of hardware, software and organizational structure. After the COPS Baseline 
Assessment is completed, the authors, working with the Security Officer, will verify that 
LEVRAS should replace COPS. A methodical approach will then be taken in the systematic 
design and construction of our product. LEVRAS system development will use the five- 
phase System Development Methodology (SDM), as discussed by CDR William B. Short's 
(1993) Introduction to Computer Management (IS-2000) classroom discussion. 

The five SDM phases are: 

Phase I - System Analysis 
Phase II - System Design 
Phase III - Programming 


Phase IV - Conversion and Implementation 
Phase V - Post-Implementation. 


Each phase will be developed with a quality product in mind. The Systems Analysis 
Phase will be carefully scrutinized to ensure that an accurate Requirements Specification 
(RS) document is developed. A quality RS document will help reduce future costs and 
errors. The System Design Phase will assist the authors in fully understanding LEVRAS 
requirements by developing Data Flow Diagrams (DFD's). Programming will be done with 
a state-of-the-art database software package to ensure production longevity in the system 
development life cycle (SDLC). Testing LEVRAS modules as they are being programmed 
will help reduce time spent debugging the completed and conglomerated module sums. 

Once LEVRAS 1s fully developed and tested, careful consideration will be given to 
how to implement the conversion of COPS to LEVRAS (Conversion and Implementation 
Phase). As the LEVRAS system developers, we will play an integral part in the conversion 
process. Training will also be a factor to consider prior to, during, and after the conversion. 
The LEVRAS Thesis will have to be made readily available to interested parties after the 
authors depart NPS to answer questions pertaining to LEVRAS system development; the 
Dudley Knox Library will therefore maintain a copy as part of their thesis inventory. 
Although SDM is a methodical approach to system development, a hybrid system 
development approach (using a prototype system) may be implemented to ensure that 
LEVRAS managers and users are involved throughout the entire process. The hybrid system 
development approach will help correct errors in the early phases of system development 
which could prove costly as the development process evolves into later phases. Prototyping 
will also let. LEVRAS managers and users express their information/database processing 
needs more fully. 

The LEVRAS requirements definition, database desi gn, and database application 
development software will use proprietary software otherwise known as Commercially-Off- 
the-Shelf (COTS) general-purpose software. EXCELERATOR is a requirements definition 
software package that will be used to develop LEVRAS DFD's. SALSA is a semantic object 
modeling software package that will be used to develop the LEVRAS database design. 








Paradox is a software database application package that will be used to develop a user 
interface in a windows environment. A LEVRAS User's Manual will be developed to 


familiarize managers, as well as users, in system basics and detailed system procedures. 


E. CHAPTER OUTLINE 
The chapters of this thesis will be organized as follows: 


I. Introduction. This chapter will discuss the objective, background, scope, and 
methodology. The objective states the main purpose for this thesis. The background 
discusses why the authors chose this thesis topic, in addition to the overall weaknesses of 
the current NPS vehicle management system. The scope focuses on the vehicle management 
system's functionalities and its physical layout. The methodology describes how the authors 
will attack the problem of system design, development, and implementation. Finally, this 


chapter outline section modularizes and describes each chapter in a succinct manner. 


II. Computer On-Line Police System (COPS) Baseline Assessment (including SDM ~ 

Phase | - System Analysis). This chapter will provide an in-depth look at the 

existing hardware, software, and administrative procedures used for NPS vehicle 
management operations. User inputs for improving current system functionalities and 
additional non-existing functionalities will be identified to produce a requirement 


specification (RS). 


Ill. Database Development Process. This chapter will address the key areas of a 
MIS and its administrative data that will be manipulated to produce desired information. 
This process is a generic heuristic for the development of any relational database and its 
applications. Specifically, these key areas include: database concepts, database 


development methodology, requirements analysis and specifications, database design, and 








programming. Finally, this chapter will close with system conversion and implementation, 


as well as post-implementation issues. 


IV. SDM Phase JI - System Design. This chapter will build upon the foundation 
addressed in Chapter Il. Data requirements will be researched and subsequently 
established with-the concurrence of the NPS Security. Data flow diagrams will display the 
core processes involved with the new Law Enforcement and Vehicle Registration 
Administration System. These DFDs will assist in identifying the data dictionary 


specifications used to actually develop the database and its applications. 


V. SDM Phase III - Programming. This chapter will employ semantic object 
modeling as the methodology used for modeling the LEVRAS specifications for its data 
dictionary. Semantic objects and their attributes will be created using "SALSA" semantic 
object modeling software. SALSA will assist in making the LEVRAS schema, which will 
be transformed into Paradox format. Once the database tables are constructed, the GUIs will 
be built from user specifications gathered during the new vehicle registration system 
assessment as described in Chapter II. The GUIs will be tied together using relational 
database concepts in the ObjectPal programming language. Thorough testing will be 
performed before providing LEVRAS to the users. To further support NPS Security 
personnel, a LEVRAS User's Manual will be written specifically for NPS Security use. 


VI. SDM Phase IV - Conversion and Implementation. This chapter will describe the 
actual conversion from COPS to LEVRAS, and the extensive training provided to all users 
and supervisors, which offset any anxiety inherent in the change process. A conversion from 
COPS to the new database system will be executed. Once LEVRAS is fully operational, the 
new system will allow the users to efficaciously query on demand, perform reliable back- 


ups, and conduct numerous other new or improved functions. 








VII. SDM Phase V - Post-Implementation. System maintenance requirements will 
be addressed in the LEVRAS User's Manual. After fulfilling all system installation 
requirements, the NPS Security Officer will sign the “System and Acceptance Test" 
document, which will signify his approval of LEVRAS. 


VIII. Conclusions and Lessons Learned. This final chapter will summarize the 
System Development Methodology process and project team concepts to be employed by 
the authors during this thesis. It will further expand on the author's interpretations of the 


overall system design and implementation process that will greatly enhance future system 


developers' efforts. 














Hi. COMPUTER ON-LINE POLICE SYSTEM (COPS) BASELINE ASSESSMENT 
A. EXISTING VEHICLE REGISTRATION SYSTEM 


This chapter will provide an in-depth look at the existing hardware, software, and 
administrative procedures used for NPS vehicle management operations. COPS is a mid- 
1980's computer system that reduced man-hours for filing and retrieving records, and 
enhanced organizational clarity in security administration procedures. Training was also 
minimal since the COPS program GUIs are displayed in a lucid fashion and the procedures 
to operate COPS are mechanized. The existing system hardware and software is outlined 
in Table 1 below: 
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Printer 
pe 




















SpEKEN pa 
COPS (Dbase II 


Manual Card File 11,000 Active 5x8 Cards and 
Archive over 50,000 Cards 
Consumables Varies Fanfold Paper, Floppies, 
Tape Cartridges, Printer 
Ribbons, and Index Cards 
Controlled Consumables Varies Vehicle Decals and 
Temporary Passes 


Office Equipment Desk, Chair, and File Cabinet 


Table 1. COPS Hardware, Software, and Ancillary Equipment 








Presently, users of COPS enter, modify, delete, store, and display vehicular 
information on vehicles registered at NPS using a primitive flat-file database technology. 
All COPS hardware and software are located within the VIRO, building 211, and building 
200, the home of the NPS security forces. The present system cannot ensure accurate 
information, resulting in errors that are inexcusable and embarrassing for the NPS Security 
Department. These errors result primarily from the data entry phase (data entry clerk 
typographic errors) and the possibility of loss of information due to system failures in 
between the infrequent backups (backups are conducted anywhere from one week to one 
month). Also, there is not an adequate procedure to track vehicles that are no longer 
registered at NPS. The Administrator scans over the entire vehicle registration database by 
pulling each record (one-by-one), checking vehicle registration expiration status. This 
Standard Operating Procedure (SOP) is excruciatingly slow. The many outdated records 
remaining in the database cause an increase in the mean time to respond to database queries. 

Another major problem is data archiving. Once a vehicle leaves the system, only a 
hard-copy file is maintained in the VIRO's file cabinet. Data retrieval under this system is 
also archaic, as clearly exemplified in the "La Mesa child abduction attempt" previously 
cited in the Background portion of the Introduction. Manually sorting through thousands of 
archival records can take virtually hours, days, or even weeks to locate a record of concern. 

Several other deficient areas were noted during our assessment. The major 


deficiencies include: 


0 Local _area-networking is nonexistent. COPS consists of two similar 
stovepipe subsystems, which communicate via physically transporting floppy 
diskettes between the VIRO site and the Security site. 


0 Inter-networking is nonexistent. No computer data-link exists between 


COPS and other military installations or any outside law enforcement 
agencies such as the local police force, California Highway Patrol (CHP), 


and other police forces nationwide. 


10 











COPS hardware and software _is obsolete. COPS no longer supports the 
functionalities required by the NPS Security Department (as discussed in this 
list). 


Data entry is manual and subject to inaccuracies. Data entry clerks are prone 
to typographical errors and input data in wrong formats. COPS software 


was not programmed to prevent simple referential data errors. 


Database archiving and backups are inadequate. VIRO's Irwin Tape Drive 
Cartridge Backup System is capable of backing-up COPS data; however, it 
is a single point of failure that has failed. This last point ties in directly with 


the next item in this list - system maintenance. 


System maintenance is nonexistent. Presently, a COPS maintenance contract 
does not exist. Data entry clerks are reluctant to notify management of 
COPS subcomponent failure (due to physical barriers such as different 
buildings or different offices within the same building), thereby causing 


degraded system functionalities. 


COPS is vulnerable to virus penetration and other security breaches. 
Exchanging floppy diskettes between computers is a very dangerous practice 
since this can spread a virus from an infected computer to an unprotected 
computer. COPS is also vulnerable to computer infection and privacy act 
violations by any subreptitious virus program or other intrusions whenever 


operators leave their terminals. 


Query capability is limited. The query process involves manually looking 
through index cards or performing a computerized query on only one of the 


i] 





following fields: name, social security number, license plate, decal, and 


ticket. 


C Administrative procedures are weak. The sole document for governing 
COPS keyboard entries is the COPS User's Manual, which is written and 
distributed by the Naval Computer and Telecommunications Station (NCTS), 
San Diego. This manual only delineates the type of data that needs to be 
entered in a specific field on a specific screen. For example, on the Decal 


Entry Screen, this manual states: 


Enter the required information in the blank field provided. 
Validation of data entered is done for "DECAL NUMBER", 
"EXPIR YR", "“EXPIRMO", "LICENSE NUMBER", 
"VEHICLE BODY", VEHICLE MAKE", and "VEHICLE 
COLOR". (NCTS San Diego, 1991, p. 13) 
Although the COPS User's Manual provides data entry instructions, it lacks 
a standard operating procedure (SOP) that could be used throughout 
DoD. When the VIRO Administrator is absent from the COPS workstation, 
the vehicle registration process ceases. An SOP would alleviate this major 


problem, as well as other security and customer related topics. 


It is clearly evident that COPS is riddled with numerous problems which include data 
field ambiguities, severe query limitations, and weak security safeguards. Some of these 
discrepancies are small, but unfortunately many are large and are inherent in the present 
method of the COPS database operations. Although the paper filing system is a somewhat 
effective way to archive and backup data, it is extremely slow and inefficient. The 
technology of today offers several solutions to the deficiencies described above, as 


delineated in the following sections. 
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B. (NEW VEHICLE REGISTRATION SYSTEM ASSESSMENT 
(SDM PHASE I - SYSTEM ANALYSIS) 


All the problems described above were discussed in detail with the NPS Security 
Officer and his staff. User inputs for improving the current system functionalities, as well 
as additional non-existing functionalities were identified during these discussions. The 
format used in this section will first list the previously identified problem, and then provide 
the authors’ recommendations for improvement based on the Security Department 


personnel inputs. 


O Problem: Local area-networking is nonexistent. 

Solution: The authors suggested that a local area network (LAN) be designed 
to connect the Vehicle Registration Office (building 211) and the NPS Base 
Police Station (building 200). As a result, Security Department generated 
MIS contract was approved for connection of the two independent 
workstations. These workstations are now located within the same building, 
the NPS Police Station. This strategy improved the entire intra- 

communication process among the VIRO and Security personnel. The 
probability of complete, accurate, and timely data transfer within the 
department is dependent on hardware and software exchange which now 


minimizes the negative effects of the human intervention process. 


0 Problem: Inter-networking is nonexistent. 
Solution: A modem and communication software should be incorporated 
into the LEVRAS system to facilitate communication with other law 
enforcement agencies, DoD security forces at other locations, and on- 


campus officials not included on the LEVRAS LAN. This will provide 
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rapid police data exchange between these agencies, and further assist in 


timely police response. 


Problem: COPS hardware and software is obsolete. 
Solution: A new suite of hardware and software will be provided with 
LEVRAS, gaining speed, reliability, and increased functionality. The new 


hardware components will most likely include: 


(2) IBM Compatible 486, 66 Megahertz (MHZ) computers 
(2) 8 Megabyte (MB) Random Access Memory (RAM) 
(2) 1 Gigabyte (GB) Hard Drives 

(2) Network Interface Cards (NIC) 

(2) Laser Printers 

Coaxial cabling and connectors 

Modem, 14.4 Bits Per Second (BPS) 

Uninterrupted Power Supply (UPS). 


The new software components will most likely include: 


Communications (Modem) Software 
Network Software 

Anti-Virus Software 

Paradox Database Software 


Semantic Object Modeling Software. 
Problem: Data entry is manual and subject to inaccuracies. 


Solution: The LEVRAS database entry screens will substantially reduce data 
entry errors through validity checks that will ensure that data is correct and 
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appropriate. "Validity checks help to minimize data errors by checking the 
data before it is placed in the table [database]." (Rock, 1993, p. 277) 


Problem: Database archiving and backups are inadequate. 
Solution: The new LEVRAS system will include two, one gigabyte hard 
drives, for complete archival and database backup as noted above in the new 


hardware component list. 


Problem: System maintenance is nonexistent. 

Solution: A comprehensive MIS system hardware maintenance plan was 
included in the LAN installation contract. Database software maintenance 
can be accomplished by in-house personnel using the LEVRAS User's 


Manual and other references, or outside contractors. 


Problem: COPS is vulnerable to virus penetration and other security 
breaches. 

Solution: The LEVRAS will use commercial-off-the-shelf (COTS) anti-virus 
software, which will help reduce numerous security vulnerability problems. 
The software should be a reputable COTS product, such as Norton Anti-Virus 
or McAffee Anti-Virus software. Other security improvements include the 
relocation of VIRO computer to NPS Security Police Headquarters, which 
is manned continuously. This improves security by providing 24 hour 


supervision of the entire LEVRAS system. 


Problem: Query capability is limited. | 
Solution: The LEVRAS is based on Paradox, which provides a complete and 

flexible relational database management system with a comprehensive query 
capability. Paradox users can query on anything from a simple question 


about the information in one table, to a complex question about the 
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information in several tables. In a Paradox query you can specify: tables to 
ask questions about; fields you want to see in the answer; records you want 
to select; calculations you want to perform; and answers to ‘what if 
questions. Queries can also perform operations that: insert new records; 
delete records; change values; and create new fields. This enhanced query 
function of the vehicle registration database is the primary reason why the 
authors and the NPS Security Officer decided to upgrade COPS. 


O Problem: Administrative procedures are weak. 
Solution: The authors will provide a comprehensive LEVRAS User's 
Manual, which will assist in the development of a SOP specifically for 


vehicle registration, security and other relevant procedures. 


The proposed LEVRAS system will be specifically designed to support the NPS 
Security Force. It's primary function will be to provide a state-of-the-art relational database 
management system with a comprehensive query capability, providing accurate, timely, and 
complete vehicular, owner, decal, and ticket violation information to NPS Law Enforcement 
Officials. Functional improvements are included in the table on the following page. The 
solutions to the problems described above and the proposed LEVRAS characteristics 
presented on the following page in Table 2, will be the foundation for this project's 


requirements specification (RS). 


16 








Spee en cnn eee tone enpteehertemeatedehiedeetenmmeetsediademae ae en nnnn cece eer c rere s ee ree reece eee eee eee eee eee ee ee Ee TT tay 


Specific content of Increased content to meet Basic vehicular registration 
information outputs user needs data 
Selectivity Extensive data query Limited data query 
| capabili capabili 
Time lags Fast 80486 Central Processor | Slow 80286 CPU 
Unit (CPU), 66 MHZ | 
Accuracy of outputs Increased accuracy using Susceptible to data entry 
validity checks errors 


Reliability No UPS & backups 
unreliable due to a 
malfunctioning Irwin tape 
drive 


— 


















Increased reliability using 
UPS and internal hard drive 
backups 












Generality General enough for both 


ticket and VIRO processing, 


Not general enough: 
ticket processing done on 







& understandable two separate systems and the 
information information is too narrow in 
for supervisor reporting scope 


Flexibility Easy to modify Paradox's Moderately difficult to 
ObjectPal code change program dBase code 


Table 2. Proposed Characteristics of LEVRAS vs. COPS 


This section discussed the existing vehicle registration and security information 
system with the proposed new LEVRAS system. The NPS Security Officer, as well as the 
authors, feel that there is an overwhelming need to improve the existing system's hardware 
and software due to the inherent COPS functionality deficiencies. The SDM Phase I - 
System Analysis is now complete. The following chapters will discuss the authors' design 


and implementation of the new system. 
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Tit. DATABASE DEVELOPMENT PROCESS 


This chapter will begin with a conceptual view of what the new information system 
will necessitate. The scope of this thesis will be narrowed to identify what kind of 
information system is appropriate for the new system. Once it has been determined what 
kind of information system LEVRAS will require, then the database design will be 


developed in order to properly manipulate the data to meet all functional requirements. 


A. BASIC DATABASE CONCEPTS 


LEVRAS will be a management information system (MIS). The reason for this 
1S: 


An MIS is an integrated structure of databases and information flow 
that optimizes the collection, transfer, and presentation of information 
throughout a multilevel organization whose component groups perform a 
variety of tasks to accomplish a united objective. (Long, 1993, p. 441) 


Although a typical MIS may be incorporated into large corporations with many departments, 
LEVRAS is narrower in scope and breadth. LEVRAS still fulfills the definition of a MIS, 
since it contains the core elements, such as an integrated database structure that pulls 
together many data elements of the organization in a relational manner. 

The key to the proper operation of the envisioned new system is its relational 


database. A relational database encompasses the following: 


A two-dimensional array containing single-valued entries and no 
duplicate rows. The meaning of the columns is the same in every row. The 
order of the rows and columns is immaterial. (Kroenke, 1992, p. 640) 


19 





A database is: 


A self-describing collection of integrated records... it contains, in 
addition to the user's source data, a description of its own structure. This 
description is called the data dictionary... A database is more than a 
collection of files. A database includes files of source data plus a description 
of the relationships among the records in the files. These relationship 
descriptions are stored and recalled during database processing. (Kroenke, 

1992, pp. 12-14) — 

The relational database described above will be beneficial to LEVRAS for three 
reasons. First, the organizational layout of the database will be conceptually easy to 
understand due to its two-dimensional format of columns and rows. Second, the 
relationships between the data elements will be easily comprehended by users. For example, 
a VIRO customer may have multiple vehicles. Third, this database structure can be used to 
support many functional applications such as transaction processing, supervisor reports, and 


assistance to decision-making. 


B. DATABASE DEVELOPMENT METHODOLOGY 


During the LEVRAS database development process, the five phases of the System 
Development Methodology (SDM) will capture the essence of the intended application 


functionalities. The phases are described below: 


o SDM Phase I - System Analysis (determine the project objective): 
- Form project team: team leader, programmers, system specialists. 
- Define the problem: team members consolidate their respective views to 
establish a consensus definition of the project objective. 
- Establish scope: prioritize the required functions and choose the functions 
above a set threshold. 
- Assess feasibility: determine and evaluate political, economic and technical 


constraints. 
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- Develop requirement specifications (RS) to meet user's needs: includes 


the desired inputs, outputs, and process constraints. 


SDM Phase II - System Design (determine what the system must do): 

- Determine functional components: update, display, and control 
mechanisms. | 

- Create user's process model: describes the organizational processes and the 
objects to be stored in the database. 

- Reassess requirements: finalize system requirements. 

- Reassess feasibility: determine if the chosen architecture remains feasible 


and present to systems sponsor for review and approval. 


SDM Phase Ii - Programming (determining how the system will operate): 

- Use prototypes: Working model of forms, reports, and menus for user 
review and feedback. 

- Select systems architecture: choose the best data model that meets user's 
requirements. 

- Develop database design: objects, attributes, and relationships. 

- Construct database: create database schema based on object design. 

- Develop application design: menus, data entry screens, query schemes, 
reports, and control mechanisms. 

- Build applications: create user interfaces with a programming language to 


link the menu and data screens to required system tasks. 


SDM _ Phase IV _- Conversion and Implementation (construct system in 


accordance with its design): 


- Choose best conversion method: abrupt cutover, parallel, location, or 


staged. 
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- Train users and maintenance personnel: User's manual, other references, 
and hands-on. 

- Install database and applications: insert new programmed database 
software and its relevant data into the desired system hardware. 

- Conduct System and Acceptance Test: system sponsor approve new system 


operation. 


O SDM_Phase V_- Post-Implementation Phase (support for long term 
operations). 
- Complete and deliver the user's manual: include operator help and 
maintenance guidance. 


- Execute system maintenance plan: routine and corrective. 
C. TECHNICAL DATABASE CONSIDERATIONS 


This section will address project team concerns regarding the fabrication of the 
database. The project team will then take these concerns and determine the functional 
components of each application that will be used in the database. There are two ways to 
fulfill the user's requirements and build the user’s database. Specifically, these development 
methods are the top-down and bottom-up styles. The top-down approach takes a broad view 
and narrows the scope to specific functionalities. The bottom up approach first takes a 
myopic look at the organizational tasks, and then broadens its view outward to the strategic 
goals. Combining both the top-down and bottom-up styles is known as the hybrid database 


development methodology. 
I. Data Flow Diagrams 


Data flow diagrams (DFDs) will be used to provide the project team members with 
a conceptual view of the data to be used throughout the database and its related applications. 
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DFDs will also be used to identify the data flow through a system and determine the work 
processes required to implement system functions. Figure 1 depicts a generic DFD. 


Descriptions of the DFD components will follow the diagram. 





Figure 1. Generic Data Flow Diagram 


DFDs are comprised of the following components: 


C7 Process: performs a transformation on the incoming data flows, that is, the 
outgoing data flows will contain data that has been altered from the original 
incoming data. There must be at least one incoming and one outgoing data 


flow for each process. 


0 Data Flow: is equivalent to a "pipe" that carries information from one source 
to another. One of these sources must be a process. The data flow can also 


be coming from an entity or a data store. 


C Entity: also known as sources or destinations. Entities provide inputs an 
outputs to the system. These inputs and outputs can be located inside 


processes or outside the system. 
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0 Data Store: synonyms include file and database. The data store does exactly 
what its name implies, it stores the data for the system. New data can be 


entered in the data store, and then retrieved, manipulated, or deleted. 


The data flow diagrams are exploded, or decomposed, until primitive DFD levels 
display the basic process and data flows, which will help define the system data 
requirements. Computer-Aided Systems Engineering (CASE) tools, such as 
EXCELERATOR by Intersolv, can be used to transform the DFDs into their respective 
database applications. Another alternative is to manually convert this information into 
semantic object models, as discussed in the previous section. In either case, a data 
dictionary will be created that will contain the descriptions of the primitive data 


requirements derived from the DFDs. 
he Data Dictionary 


The data dictionary will capture the DFDs themselves, as well as the requirements 


and specifications definitions that the DFDs provided. 


A database is self-describing: it contains, in addition to the user's source 

data, a description of its own structure. This description is called the data 

dictionary (or data directory, or meta data). It 1s the data dictionary that 

makes program/data independence possible. (Kroenke, 1992, p.13) 

A customer receiving a receipt at the check-out counter, for example, would provide 
a picture of data flowing from a check-out process to a customer entity. In addition, the 
customer attributes, the data elements contained in the data flow, and the process definition 


would all be described and stored in the data dictionary. 
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a B Semantic Object Modeling 


Developing the database will require the project team having a good grasp of what 
is needed in the form of data. This data will be represented in the form of objects (using 
semantic object modeling) and their respective attributes. Figure 2, on the following page, 
provides an example of a semantic object and its characteristics. Definitions that explain 
the semantic object and its characteristics precede the figure. 


The overall view of semantic object modeling can be described as follows: 


0 Semantic Object: a person, place, or thing. Relevant data about these 
objects is stored within the database. Example - CUSTOMER (person), 
VIRO (place), TICKET (thing). 


0 Attribute: describes the semantic object in these forms - simple, group, 
formula, or semantic object link. Example - CustomerID (simple), 
CustomerName (group), TicketPoints (formula), SocialSecurityNumber 


(semantic object link). 


O Identifier: attributes that are used to distinguish an instance of a semantic 
object, which can be unique or nonunique. Example- CustomerID (unique) 


and CustomerName (nonunique). 


0 Subtype Semantic Object: a parent semantic object broken down into 
children, and are more specialized or specific about the parent. Example - 
AUTOMOBILE (semantic object or parent) specialized to MOTORCYCLE 
and TRUCK (subtype semantic objects or children). 
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Cardinality. The minimum or maximum amount an attribute can 
characterize one instance of a semantic object or of a group attribute. 


Example - one CUSTOMER to many AUTOMOBILES. 


Domain: describes the set of possible data types and formats available for 


use in the database. Example - SocialSecurityNumber 123-45-6789. 


ID ObjectiID 
SimpleAttributel 1.N 


GroupA ttribute! 
ListItem1 1.1 
Listltem2 0.1 
Listitem3 1.3 


Formulal 1.N 


SUBTYPE] 0.ST 
SEMOBSLINK! LN 


Figure 2. Generic Semantic Object 
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The database will be developed using more than one requirement. Using multiple 
requirements will cause these requirements to overlap, and will create more complexity in 
the overall database. Requirements that are identified properly from the outset of the project 
will greatly deter the dreaded occurrence of analysis-paralysis. 

The database design is an important part of the relational model because it will be 
used to delineate database management system (DBMS) independent designs. In other 
words, semantic objects defined in the data dictionary and their characteristics will be more 
clearly solidified. A social security number, for example, will be formatted to contain the 
proper domain of physical properties to include data type (positive whole numbers), field 
size (11 elements including the hyphens between the numbers), and value constraints (zero 
to nine). Semantic object modeling will assist in capturing the meaning of the data to be 
modeled. It deals with objects and their characteristics to determine which data is to 
maintained and how to handle the relationships between the objects. This information is 
further used to create a database that will eventually be transformed into relational tables. 
These tables will allow the users of the system to maintain a relevant database that may 
provide a wide-range of services including multi-table: forms, reports, screens, and queries. 

The following heuristic can be used to develop the semantic object model (refer to 


Figure 2. Generic Semantic Object): 


a. Step 1. Retrieve semantic objects from the data dictionary. If applicable, 
determine which semantic objects will be the parent and their respective children. Also, 


links can be made between objects. 


b. Step 2. List all of the attributes for each semantic object to be modelled. There 
are simple and group attributes. Group attributes can be uniquely defined by grouping list 
items (sub-attributes) under the group attribute heading. If applicable, determine any 


formulas relevant to the object. 
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c. Step 3. Choose one semantic object attribute that tags the selected object. This 
will uniquely identify the object to distinguish itself from other like objects. 


d. Step 4. Determine the value and format for each of the attributes. The physical 


properties of the attribute can be described as a data type, field size, or value constraint. 


e. Step 5. Assign the cardinality of an attribute that describes one instance of a 
group attribute or semantic object. An instance is an actual person, place, or thing rather 


than an abstract object. 


f. Step 6. Generate schema. A schema describes the database to the DBMS; 


however, it will not cause any of the actual data elements to be entered. 


After the schema has been generated, the information system designers can 
commence work on the generated tables within the respective database software program. 
This schema provides the foundation upon which the applications, such as forms, screens, 


and reports can be built. 
4, Database Application Design 


Designing the applications for the database will require the programmers to know 
how to make the software capture the essential functional and data requirements. “An 
application is an integrated collection of related features that permit you to perform a task." 
(Jensen and Anderson, 1994, p. 4) At this point in the system development methodology, the 
software moves from logical to physical structures (programs and data files). These 
structures define programs to carry out specific system functions such as entering data and 
printing multi-table reports. In presenting the design graphically, the programmers will be 
able to use different representations within Paradox's ObjectPal programming language. 


Some graphic design options include: radio buttons, scroll bars, and dialog boxes. 
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When developing the software components, programmers should create the program 
in sections from smallest to largest: first program units (tables), then modules (groups of 
tables) supporting the major processes, the interfaces among modules and with external 
systems (LAN nodes). The program will be debugged (tested) as the program is being built 
to prevent small errors from expanding into large and potentially costly errors. Testing 
includes the following: unit, module, and system integration testing. When programs are 
debugged and the errors are removed, documentation should be written for future reference 
to support training and maintenance. Also, programmers should ensure that when an error 
is detected and corrected that it does not affect other program parts. Documentation will 
also be written in incremental stages to provide the users and maintenance personnel with 
a well written and complete user's manual (finalized in the implementation phase). 

Now that the program code has been written to meet the system requirements, the 
user's will be able to see the finished product. The finished product includes all of the 
functionalities as they pertain to their physical attributes. These physical attributes include: 
how the user will open the program; what the opening presentation screen will display; how 
to enter data into input screens and how these screens will appear to the user; what kind of 
effects feature buttons and pull-down menus will have on the database and its applications; 
what kind of output data will be presented on reports; and how to exit the program during 


a session. This system is now ready to be delivered. 
5. System Conversion and Acceptance Test 


System conversion can be implemented by a variety a methods: abrupt cutover, 
parallel conversion, location conversion, and staged conversion. The following paragraphs 
will address each of the conversion approaches individually. The remainder of this section 
will address the system acceptance test. 

The abrupt cutover uses a rapid approach to system conversion. On a specific date, 
the old system will be tuned-off and the new system will be turned-on. This is considered 


a very high-risk approach to system conversion. If the new system crashes, then there is a 
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strong possibility of having a long recovery time, which would be unacceptable for mission 
critical operations. If an organization cannot afford any system down time, then it is 
recommended that another conversion approach be used. 

Parallel conversion simultaneously uses both the new and old system during the 
conversion stage. This is considered a low-risk conversion process since both systems are 
being used. If one system crashes then the other system is used without losing any 
information. This approach is best utilized on mission critical systems that cannot afford 
to sustain any downtime. A drawback of this approach is that it takes more manpower and 
resources to run two systems simultaneously. 

Location conversion is used when an organization is going to replace many of the 
same systems. The organization will choose one of several departments that will be 
converting their information systems. This one department will be the test bed for all other 
departments undergoing future information system conversions. Lessons learned can be. 
gathered and used to smooth all other future conversions. This method is also considered 
a low-risk approach since only one department will sustain a temporary loss of operations 


if the new system should crash. 


Staged conversion can best be summarized as follows: 


Like location conversion, staged conversion is a variation on the 
abrupt and parallel conversions. A staged conversion is based on the version 
concept introduced earlier. Each successive version of the new system is 
converted as it is developed. Each version may be converted using the 


abrupt, parallel, or location strategies. (Barlow, Bentley, and Whitten, 1994, 
p. 740) 


The systems acceptance test is the major and final activity that occurs during system 
conversion. The systems acceptance test can be defined as the final system test, which will 
be performed by the end-users. The users will use real data during this test. After successful 


completion of the systems acceptance test, the sponsor(s) will take custody of the system. 
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6. Documentation, Training, and Maintenance 


A key factor in the successful support and maintenance of software is complete and 
comprehensive documentation. The manuals should be written to support users and 
maintenance personnel. Meeting requirements for system documentation is the objective 
factor; however, the subjective factor of quality is actually the more crucial part of this 
document. In other words, the user's manual should aid both the users and maintenance 
personnel in the performance of their jobs. | 

Training the end-users to effectively operate the new system is also an important 
factor in ensuring that the systems is fully used. Training should take place during the 
implementation phase, and if possible even earlier, to make the conversion process run 
more smoothly. This training entails reading the user's manual, as well as hands-on training 
with portions of the new system. 

Another technical consideration is the maintenance plan. The project team should 
deliver a well thought out method for the information system sponsor to employ a routine 
preventive maintenance plan, as well as pursue equipment repairs when needed. This 
maintenance plan should also include information and references, in case users desire to 
upgrade system functionalities. Three avenues for maintenance personnel include: the 
user's manual, other reference manuals and user's guides (for example, Borland Paradox for 


Windows User's Guide and the Guide to ObjectPal), and as a last resort, use hired 


contractors. 
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IV. SDM PHASE I - SYSTEM DESIGN 


In Chapter Il, SDM Phase I - System Analysis, the authors identified inherent 
problems with the current security Information System (IS). Potential solutions to these 
deficiencies were also presented. In Chapter II, Section C, Technical Database 
Considerations, the authors discussed other factors that will assist in the development and 
design of the improved IS. The result of these efforts is the Requirements Specification 
(RS) delineated in Appendix A. This RS is a conglomeration of functional and non- 
functional requirements including: the input of data, the processing and storage of this data, 
and system outputs. For example, a vehicle model is entered into the database, and the NPS 
Security Officer is presented a summary listing of all the Ford Pintos currently on file. 

The remainder of this chapter will be devoted to the development of specific data 
objects and processes using the RS. Data flow diagrams will be constructed to help define 
each of these system elements. The final product should be a data dictionary containing — 


element descriptions to be used in the next phase of IS development. 
A. DATA FLOW DIAGRAMS 


Chapter II presented the basics of data flow diagram (DFD) theory, as it applies to 
the development of the new Law Enforcement and Vehicle Registration Administration 
system (LEVRAS). In this section, DFDs were actually created for LEVRAS, using a 
computer aided systems engineering (CASE) tool. These DFDs are contained in Appendix 
B, and are discussed below. As mentioned previously, these DFDs will be used to transform 
the RS into data dictionary definitions. 

The first step in developing DFDs 1s the construction of the decomposition diagram. 


The LEVRAS Decomposition Diagram, located in Appendix B, provides an overview of 
LEVRAS DFDs. 


33 





LEVRAS is composed of three primary levels, and includes the following processes: 


LEVEL PROCESSES 
First Level LEVRAS (Overall System) 
Second Level Process | - Process Customer Checkin 


Process 2 - Process Customer Checkout 
Process 3 - Generate Query Response 
Process 4 - Process Tickets 

Process 5 - Generate Reports 


Third Level (Primitive) Process 1.1 - Input Customer Data 
Process 1.2 - Modify Customer Data 
Process 1.3 - Generate Vehicle Decal 
Process 1.4 - Generate Temporary Pass 


Process 2.1 - Process Data Transfer 
Process 2.2 - Archive Customer Data 


Process 3.1 - Validate Requested Data 
Process 3.2 - Generate Query Response 


Process 4.1 - Input Ticket Data 
Process 4.2 - Process Ticket Disposition 
Process 4.3 - Archive Ticket Data 


Process 5.1 - Generate Ticket Report 
Process 5.2 - Generate Decal Report 
Process 5.3 - Generate Customer Report 
Process 5.4 - Generate Custom Report 


The next step in the DFD process is to display how LEVRAS relates to its 
environment, using a context diagram. The LEVRAS Context Diagram (First Level) consists 
of one process (LEVRAS, the overall system), three entities (CUSTOMER, SECURITY 
OFFICER, POLICEMAN), and six associated data flows (see Context Diagram in Appendix 
A). The primary utilization of the system is centered around the ability of the SECURITY 
OFFICER (and his staff) to access customer (NPS student, staff and contractors) vehicular 
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and supporting data on a real-time basis. Information from the CUSTOMER and the 
POLICEMAN entities populates and updates the database to provide current information to 
the SECURITY OFFICER at all times. 

The context diagram is exploded (decomposed) to reveal the next level of 
granularity. The LEVRAS Second Level Diagram consists of five processes (PROCESS 
CUSTOMER CHECKIN, PROCESS CUSTOMER CHECKOUT, GENERATE QUERY 
RESPONSE, PROCESS TICKETS, and GENERATE REPORTS), three entities 
- (CUSTOMER, SECURITY OFFICER, and POLICEMAN), three data stores 
(CUSTOMER/VEHICLE DATA, TICKET DATA and ARCHIVE DATA), and the 
associated data flows (see Appendix A Second Level Diagram). 

Referring to the Second Level Diagram, the SECURITY OFFICER is centrally 
located and is able to submit query requests and receive query responses for all system data 
through Process 3, the "Generate Query Response" process. In addition, the SECURITY . 
OFFICER utilizes Process 4, the "Process Tickets" process, to receive information on and 
dispose of tickets. Finally, the SECURITY OFFICER uses Process 5, the "Generate Reports" 
process, to request and receive system data printouts. | 


The following describes the Second Level Data Flows: 


The CUSTOMER provides data to the system through Process 1, the 
“Process Customer Checkin" process and Process 2, the "Process Customer 
Checkout" process. The system responds with decal or pass assignment (not 


shown as a data flow since it is implicit) and a checkout complete report . 
The POLICEMAN interfaces only through Process 4, "Process Tickets", 


which he or she uses to enter ticket information and in turn receives a 


completion report from the system. 
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The three data stores previously discussed compose the system database, and store 


system information. The Second Level Diagram also contains numerous data flows that 


accomplish the interfaces between the data stores and the five Second Level processes. 


The final step of the DFD process is to decompose the Second Level DFD into its 


most primitive form. Descriptions of the five primitive DFDs are as follows: 


O 


Third Level DFD (Processes 1.1P - 1.4P). Consists of four processes (INPUT 
CUSTOMER DATA, MODIFY CUSTOMER DATA, GENERATE 
VEHICLE DECAL and GENERATE TEMPORARY PASS), one entity 
(CUSTOMER), one data store (CUSTOMER AND VEHICLE DATA) and 
associated data flows. Data is input and displayed in Process 1.1P and 
displayed and modified in Process 1.2P. Once the data is input, transactions 
to the CUSTOMER include "Decal Assignment" and "Temporary Pass 
Assignment". 


Third Level DFD (Processes 2.1P - 2.2P). Consists of two processes 
(PROCESS DATA TRANSFER and ARCHIVE CUSTOMER DATA), two 
entities (CUSTOMER and SECURITY OFFICER), two data stores 
(CUSTOMER AND VEHICLE DATA and ARCHIVE DATA) and 
associated data flows. CUSTOMER data is displayed and deleted from the 
CUSTOMER AND VEHICLE DATA data store and transferred to the 
ARCHIVE DATA data store via Processes 2.1P and 2.2P. | 


Third Level DFD (Processes 3.1P - 3.2P). Consists of two processes 
(VALIDATE REQUEST DATA and GENERATE QUERY RESPONSE), 
one entity (SECURITY OFFICER), three data stores (CUSTOMER AND 
VEHICLE DATA, ARCHIVE DATA, and TICKET DATA) and associated. 
data flows. The SECURITY OFFICER entity represents the initiation of 
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control processes in the system rather than an item to maintain data on. 
Transactions at this level include a "Query Request" via processes 3.1P and 


3.2P, which result in a properly formatted "Query Response" back to the 
SECURITY OFFICER. 


Third Level DFD (Processes 4.1P - 4.3P). Consists of three processes 
(INPUT TICKET DATA, PROCESS TICKET DISPOSITION, and 
ARCHIVE TICKET DATA), two entities (POLICEMAN and SECURITY 
OFFICER), two data stores (TICKET DATA and ARCHIVE DATA) and 
associated data flows. The SECURITY OFFICER entity represents the 
initiation of control processes in the system. The POLICEMAN entity inputs 
ticket data. Once the ticket data is input and displayed in Process 4.1P, 


Process 4.2P is utilized to process the ticket disposition. 


Third Level DFD (Processes 5.1P - 5.4P). Consists of four processes 
(GENERATE TICKET REPORT, GENERATE DECAL/PASS REPORT, 
GENERATE CUSTOMER/VEHICLE REPORT, and GENERATE 
CUSTOM REPORT), one entity (SECURITY OFFICER), three data stores 
(TICKET DATA, CUSTOMER AND VEHICLE DATA, and ARCHIVE 
DATA) and associated data flows. The SECURITY OFFICER entity 
represents the initiation of control processes to specifically request and 
receive reports. Transactions consist of the generation of four types of 
reports via the following four processes: Process 5.1P (GENERATE 
TICKET REPORT), Process 5.2P (GENERATE DECAL AND 
TEMPORARY PASS REPORT), Process 5.3P (GENERATE CUSTOMER 
AND VEHICLE REPORT), and Process 5.4P (GENERATE CUSTOM 
REPORT). The CUSTOM REPORT can be tailored according to the 
specific needs of the SECURITY OFFICER on a real-time basis. Note the 
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presence of all three data stores at this level, facilitating complete access to 


all system information. 


The proposed LEVRAS system is being specifically designed to support the NPS 
Security Force. The above processes compose the core of LEVRAS. Its primary function 
will be to provide a state-of-the-art relational database management system with a 
comprehensive query capability providing accurate and complete customer, vehicular, and 
ticket violation information to NPS law enforcement officials in a timely manner. All RS 
Primary Functional Requirements contained in Appendix A, are included in the primitive 
level DFDs above. 


B. DATA DICTIONARY 


In Chapter III, Section 2, a generic data dictionary was defined. This section, along 
with Appendix C, specifically elaborates on the LEVRAS Data Dictionary. The LEVRAS 
Data Dictionary includes: LEVRAS External Entities (CUSTOMER, SECURITY 
OFFICER, and POLICEMAN), LEVRAS Processes (1.1P INPUT CUSTOMER DATA, 1.2P 
MODIFY CUSTOMER DATA, 1.3P GENERATE VEHICLE DECAL, 1.4P GENERATE 
TEMP PASS, 2.1P PROCESS DATA TRANS, 2.2 ARCHIVE CUSTOMER DATA, 3.1P 
VALIDATE REQUEST DATA, 3.2P GENERATE QUERY RESPONSE, 4.1P INPUT 
TICKET DATA, 4.2 PROCESS TICKET DISPO, 4.3 ARCHIVE TICKET DATA, 5.1P 
GENERATE TICKET REPORT, 5.2P GENERATE DCL/PASS REPORT, 5.3P 
GENERATE CUST/VEH REPORT and 5.42 GENERATE CUSTOM REPORT), LEVRAS 
Data Stores (CUSTOMER AND VEHICLE, TICKET DATA, and ARCHIVE DATA), and 
their associated LEVRAS Data Flows. Finally, the LEVRAS Data Dictionary will be used 
as the foundation for SDM Phase II - Programming. 
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V. SDM PHASE IH - PROGRAMMING 


In Chapter IIT, Database Development Process, the authors discussed the many 
theoretical facets of Information System (IS) design. The initial thrust of the programming 
portion of the database development process was shown to focus on the quick generation of 
a prototype system. This was done, and in fact provided much information which assisted 
in the development and design of the improved IS. First, prototype graphical user interfaces 
(GUIs) were built and shown to the users for their review. Second, sample forms and reports 
were customized to meet the requirements of the NPS Security Officer. The result of these 
efforts was specific design features to be used during programming, including the fact that 
the semantic modelling method would adequately support the construction of an effective 
database. | 


A. SEMANTIC OBJECT MODELING 


Chapter III provides a summary of semantic object modelling theory, including a 
heuristic for their development. The implementation of this heuristic will now be discussed. 
Appendix D contains the semantic objects and an expansion of the Data Dictionary in 


Appendix C, which describes the object attributes and relationships. 


a. Step 1 The LEVRAS Data Dictionary was reviewed, and all appropriate 
data objects and their elements were established. The seven objects 
were: Customer (any person requiring vehicle registration services, 
such as a Naval Postgraduate School student or a private contractor 
requiring access to government grounds), Vehicle Registration (a 
customer's valid vehicle registration), Drivers License (a customer's 
valid drivers license), Insurance Certificate (a customer's valid 
vehicle insurance policy card or statement), Vehicle (a customer's 


vehicle requiring registration), Vehicle Decal (the appropriate official 
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b. Step 2 


c. Step 3 


d. Step 4 


decal presented to a customer upon proper entry and validation of 
information using LEVRAS), and Traffic Ticket (a ticket issued by 
NPS Security Department policemen when a customer is in violation 


of NPS traffic regulations). 


Using the SALSA semantic object modelling software package, the 
objects were individually entered. These semantic objects directly 
relate to the physical objects described in step 1, and were named: 
CUSTOMER, REGISTRATION, DRIVERLICENSE, INSURANCE, 
VEHICLE, DECAL, and TICKET. Then, all the attributes addressed 
in step 1 were named, individually entered using SALSA, and assigned 
to the appropriate semantic object. For example, the CUSTOMER 
semantic object contains many attributes, including LastName, First 


Name, HomeAddress, and DutyStation. 


One semantic object attribute, which uniquely tags the selected 
object, was chosen to distinguish it from the other objects. These 
identifiers are listed first in each semantic object, and are coded by 
a preceding "ID"symbol. The CUSTOMER object is uniquely 
identified by the SocialSecurityNumber attribute, while VEHICLE can 
be distinguished by its LicensePlateNumber attribute. 


The value and format for each of the attributes were determined. 
The physical properties of the attributes including data type, field 
format and length, and a description were entered. The Attribute 
Report, which directly follows the LEVRAS Semantic Objects in 
Appendix D, shows these entries in detail. This step also involved 
establishing semantic object links. These links are shown by the 


inclusion of one or more object's names at the bottom of the listed 
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attributes for that object. For example, the CUSTOMER and 
VEHICLE object names appear as the last two items listed within the 
DECAL semantic object. 


e. Step 5 The cardinality of each attribute, which describes one instance of a 
group attribute or semantic object, was then assigned. An instance 
is an actual person, place, or thing rather than an abstract idea. For 
example, the TICKET object contains the attribute BaseJudgeName. 
When the ticket is first written, a judge may not have been assigned, 
hence a minimum cardinality of zero is required. NPS Security 
Department regulations require a single judge to disposition each 


ticket. This establishes a maximum cardinality of one. 


f. Step 6 The semantic objects and their attributes were presented to the 
users for final review, since these data models would determine 
the actual database structure. The final touches were entered, and 
then the schema was generated for our database software package, 
PARADOX. The database structure will be discussed in the following 


section of this chapter. 
The semantic objects, and descriptions of their attributes and relationships are contained 


in Appendix D. The database tables are part of the schema which was generated using 
SALSA, and are contained in Appendix E. 
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B. DATABASE APPLICATION DESIGN 


The next step in the development of LEVRAS was to build "user friendly" GUIs 
upon the database table structures, which were generated in the final phase of semantic 
object modelling (see Appendix E). As discussed in the opening paragraph of this chapter, 
a prototype was used to verify user GUI preferences. These ideas were blended with the 
many GUI construction tools provided in the PARADOX database software package to 
finalize the application interfaces. 

The first two application screens provide access to the other many program 
functions. When initially starting the LEVRAS program, a welcome screen provides the 
name of the system, as well as the "feeling" that the program has successfully loaded. The 
user can read the program title slide, and then jump to the main menu by clicking on the 
START pushbutton. (These two opening screens are contained in Appendix F). Here the’ 


system pauses, waiting for the user to select one of the following modes: 


1. Customer Data Mode. Allows the VIRO Clerk to input, modify, or archive 
customer data. The program steps the user through the following data input 
forms: Customer Personal Data, Vehicle Data, Drivers License Data, Vehicle 
Registration Data, and Vehicle Insurance Data. Once the appropriate 
information has been entered into LEVRAS and verified by the VIRO 
Clerk, the proper decal is issued to the customer, The Decal Data Input Form 
is then used to enter the decal information. Refer to Appendix G for examples 


of these data input forms. 


2. Ticket Data Mode. Allows the Ticket Administrator to input and update ticket 
information. After the customer and decal data has been entered, the user can 
enter data into the Ticket Data Entry Form. The program presents the user with 

a form similar to those previously discussed. In addition, a Ticket Administration 


screen has been included to allow later entry of ticket information, which is not 
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normally available during initial ticket data processing. This screen provides 
much of the customer, vehicle and decal data used to assist the Ticket 
Administrator in his or her duties. Refer to Appendix G for an example of the 
Ticket Data Input Form. 


3. Reports Mode. Allows the VIRO Clerk, Ticket Administrator, or other NPS 
Security Department staff member to print out routine and customized reports. 
These reports include a Customer and Vehicle Status Report, a Decal Status 
Report, a Ticket Status Report, and a Customized Report (per the directions of 
the NPS Security Officer). Refer to Appendix H for examples of these reports. 


4. Query Program Mode. Allows the NPS Security Department staff to enter any 
amount of customer, vehicle, or ticket data and obtain a list of customers or other 


desired output data matching the description of the input information. 


5. Exit Program Mode. Allows LEVRAS users to exit the database program so that 


their computers can be used for other functions, such as word processing. 


Once the various forms and reports were constructed, each of them had to be linked 
to the appropriate database tables using the structuring tools in PARADOX. This was done 
to ensure that data entered or modified using LEVRAS GUIs would be properly maintained 
in the LEVRAS database. Next, these GUIs had to be properly linked to the Main Menu, to 
allow logical and “user friendly" flow through the program functionalities. This was 
accomplished using the ObjectPAL programming language, also contained in the PARADOX 
software package. Software driven pushbuttons were also programmed using ObjectPAL, 
to assist in the easy execution of LEVRAS commands. Such commands include "Add", to 


enter a new customer record into the database, and "Back", to launch the program back to 


the previous data entry screen. Program scripts, which drive the screen linkages and 


pushbuttons, are contained in Appendix I. 








The final step in application programming was to provide for referential integrity 
and record data validity checks. The software features contained in PARADOX provide for 
these valuable functions to be added while programming. Validity checks are specifications 
which define the range of acceptable values for database table fields. These checks prevent 
improper data from being added to a record. Numbers, for example, can be prevented from 
being entered into letter only fields. The referential integrity feature enforces the 
relationships between data stored in separate, yet related tables. This ensures that like data, 
such as a social security number, is exactly the same in any table of the database in which 
it appears. These two powerful functionalities embody the key elements which make 
multitable queries possible. 

In this chapter, the authors have reviewed the key elements of the LEVRAS Data 
Dictionary to construct a prototype. T his prototype provided several GUIs and sonie of the 
functionalities set forth in the LEVRAS Requirements Specification (RS). Potential 
LEVRAS users previewed their new IS through the program "look and feel" provided by the 
prototype. The authors took the constructive comments from the NPS Security Department 
staff, revisited the LEVRAS RS and Data Dictionary once again, and created the final 
system semantic objects and their attributes. A database structure was produced from these 
objects, and the needed database functions were programmed. The authors have included 
many powerful features into the finished product, including single and multitable forms and 
reports, automatic validity checks and continuous referential integrity service, and the most 
significant RS element, the ability to query any data maintained in the LEVRAS database, 


with even the smallest amount of input data. 
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VI. SDM PHASE IV - CONVERSION AND IMPLEMENTATION 


This chapter will elaborate on Chapter III's discussion on the conversion and 
implementation process. Chapter III discussed several different conversion and 
implementation methodologies, such as abrupt cutover, parallel, and staged. The Law 
Enforcement and Vehicle Registration Administration System (LEVRAS) was installed 
using the parallel conversion methodology. The remainder of this chapter will present the 


conversion process that the authors and NPS Security personnel experienced. 


A. TRAINING 


The first step the authors used during the training process was actually letting the 
end-users provide their inputs for form and menu development. This process was iterative 
and the end-users gained more knowledge during each session. These inputs are now part 
of the LEVRAS program. The second step employed was to conduct a LEVRAS briefing 
for the NPS Security Officer and his staff. This briefing covered the LEVRAS User's 
Manual, LEVRAS program functionalities, data conversion, local area network operations 
(the LEVRAS program source code was revised to implement a read-only lock when in a 
multiuser mode), and maintenance points of contact. This briefing was conducted in an 
open forum setting to best facilitate questions and user enthusiasm for the new system. 

At the end of the LEVRAS briefing, the LEVRAS User's Manual was presented to 
NPS Security personnel for their review, which would enhance the user acceptance during 
the conversion from COPS to LEVRAS. The authors provided individualized on-the-job- 
training (OJT) to the end-users during system installation with continuous reference to the 


LEVRAS User's Manual. The installation process will be discussed in the next section. 


45 











B. CONVERSION 


The Law Enforcement and Vehicle Registration Administration System used a 


parallel conversion methodology to convert from the existing system (COPS) to LEVRAS. 


Parallel conversion. \n parallel conversion, the existing system and the new 
system operate simultaneously, or in parallel, until the project team is 
confident that the new system is working properly. Parallel conversion has 
two important advantages. First, the existing system serves as a backup if the 
new system fails to operate as expected. Second, the results of the new 
system can be compared to the results of the existing system. (Long, 1993, 
p.536) 


During the parallel conversion, we reviewed the proposed characteristics of LEVRAS 
versus COPS as discussed in Chapter II of this thesis. These characteristics explained 
proposed LEVRAS improvements to combat COPS security vulnerabilities and functionality 
weaknesses. Referring back to Chapter II, Table 2, the authors inspected the hardware and 


software upgrades as follows: 


0 Specific content of information outputs. LEVRAS now includes customized 
and standard reports, as well as hard copy query responses. 


Oj Selectivity. The new system now has an advanced query capability to 
include a selection of desired fields, and use of wildcards (if incomplete data 


is available). 


0 Time lags. The NPS Security Officer was made aware of his department's 
slow computing processing time. He upgraded all hardware to 80486 CPUs, 
with laser printers. Software was also upgraded to include MicroSoft 
Windows 3.11 and Paradox 4.5 for Windows, which both increased the speed 
of the old system software - a MS-DOS based Dbase product. 
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Accuracy of outputs) LEVRAS increased the accuracy of outputs by 
including referential integrity and validity checks during the source code 
programming. The referential integrity linked all tables together so that all 
like information is standard throughout the database. Validity checks guard 
against improper field value entry, such as preventing letters from being 


entered into number only fields. 


Reliability. The new system hardware includes a 340 MB internal hard drive 
on each workstation (two workstations are presently being used with plans 
to expand), which increases storage space for on-line processing and data 
backups. In addition, LEVRAS provides a means to save old customer data 
in its archive mode. The authors reminded the NPS Security Officer to set 
aside fiscal year 96 appropriations for UPS equipment. An UPS will provide 


NPS Security more reliability during power outages. 


Generality. Basically, COPS is comprised of two "stovepipe" systems, which 
can not share its computerized information without physically transferring 
data via a 5.25" floppy diskette. LEVRAS provides continuous on-line 
sharing of all data. Also, any system function can be performed at any 
workstation. LEVRAS was designed to be general enough for any level of 
administration, from the NPS Security Officer to the newest Security 


Department Staff member. 


Flexibility. The LEVRAS source code was provided to the MIS maintenance 
group located in the NPS Herrmann Hall building. This source code can be 


modified to accommodate for LEVRAS future growth. 
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After agreeing that the current facilities were ready to support conversion, the 
authors and the users commenced LEVRAS installation in accordance with LEVRAS User's 
Manual (See Appendix J) procedures. All system files were successfully loaded. COPS 
functions were checked to ensure availability during the parallel conversion. Live data entry 


will be discussed 1n the following section. 
C. SYSTEM ACCEPTANCE TEST 


Prior to the NPS Security Department performing their system testing, the authors 
tested and debugged program errors. The authors also selected two unbiased people to test 
the LEVRAS program for useability and system flaws. In addition, the authors' thesis 
advisors reviewed and critiqued the final product. Minor modifications were included as a 
result of this review and critique. 

The LEVRAS program was then tested by the end-users (after their initial training 
session). Actual customer records were entered and manipulated by the users under the 
supervision of the authors. New customers arrived, and LEVRAS successfully supported 
all required data storage and decal issue procedures. During lulls in the action, COPS data 
was retrieved and entered into LEVRAS. The NPS Security Officer monitored this process 
and was satisfied with the system testing results. The system met all of Security 
Department requirements to include: password security, GUI friendliness, data accuracy, 
and query capability. With the concurrence of the NPS Security Officer, LEVRAS was 
turned over to the NPS Security Department for normal VIRO and Ticket Administration 


Office operations. 
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VU. SDM PHASE V - POST IMPLEMENTATION 


This chapter will discuss how LEVRAS documentation and system maintenance will 
be handled during its system life cycle. The authors wrote a comprehensive LEVRAS User's 
Manual (Appendix J) to support the NPS Security Department. In addition, the authors 
made arrangements with NPS Management Information System (MIS) computer support 


personnel to maintain LEVRAS upon the authors departure from NPS. 


A. DOCUMENTATION 


As previously stated, a LEVRAS User's Manual was written to support daily 
operations, as well as providing references for maintenance support. The LEVRAS User's 


Manual specifically addresses the following: 


Points of contact, 

Software development, 

Deliverables, 

Diskette files list, 

Hardware and software requirements, 
Installing LEVRAS, 

System callup and passwords, 
Log-out and power-down procedures, 
Housekeeping procedures, 

Error messages, 

Tutorial for menus, data entry forms, reports, queries, and archive, 
LEVRAS codes, and 


References. 
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The references mentioned above refer the LEVRAS users to Paradox 4.5 for 
Windows and MicroSoft Windows software manuals for support of these products. In 
addition, other references will provide support to Paradox for any future upgrades to the 
LEVRAS program. 


B. SYSTEM MAINTENANCE 


Keeping within the standardized SDM procedures and lifecycle management process, 
maintenance support is available for LEVRAS. Specifically, the authors will maintain the 
LEVRAS software program until September 1995. Thereafter, LEVRAS will be maintained 
by the Management Information System computer specialists located in Herrmann Hall, 
room E-204, phone (408) 656-2195. 

The LEVRAS program script was provided to the above computer specialists for 
future upgrades and program system maintenance. For example, a LEVRAS menu could be 
modified to include another pushbutton for a new report. The actual LEVRAS menu would 
be redesigned by using the *.FSL master file associated with that particular menu to be 
modified. Then the pushbutton would be built and added onto the menu in the designated 
area. Once the pushbutton is built and its label applied, the source code would be attached 
to the pushbutton (use a previously built pushbutton within the LEVRAS source code as a 
guide). The source code would direct the pushbutton to the new report (*.RSL master file). 
The report would then be built to accommodate the user's data requirements. This report 
would be built by selecting New Report in Paradox, and following Paradox manuals 
referred to in the LEVRAS User's Manual. } 

Once the new functionalities are constructed, system maintainers would need to 
document all of their code (they can also document their source code as it is being built, 
which is a better way of writing code) within the source code itself. Once the source code 
is documented, the LEVRAS system maintainers would then print this modification or 


upgrade and add it to the original source code (provided by the authors). 
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LEVRAS system files that were provided to the NPS Security Department and the 
MIS computer specialists, would then need to be updated to reflect the new changes or 
additions. These files would then need to be installed within the operating LEVRAS 
program and tested as discussed in Chapter VI of this thesis. The files should be maintained 
on a 3.5" floppy diskette and stored in a safe location. | 

In the case of system crashes, the stored 3.5" LEVRAS program diskette can be used 
to re-install the program. Refer to LEVRAS User's Manual for program installation 
- (Appendix J). Once the LEVRAS software program is loaded, the LEVRAS user would 
need to install his or her data (located in the LEVRAS tables, *.DB working files). If by 
chance the working data tables are destroyed (*.DB working files) the daily backup files 
would be used to recover all of the destroyed data. This is why it is crucial for users to 


routinely backup their LEVRAS files, as part of their system maintenance program. 
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VHI. CONCLUSIONS AND LESSONS LEARNED 


The Law Enforcement and Vehicle Registration Administration System (LEVRAS) 
was developed for the Naval Postgraduate School (NPS), Monterey, California. This 
management information system (MIS) replaces the Computer Online Police System 
(COPS), which was plagued by typical legacy computer system problems, such as old, slow 
hardware and software riddled with functionality gaps. The NPS Security Department staff 
now performs its daily vehicle registration and ticket administration operations using 
LEVRAS. The authors’ original interest in designing and developing LEVRAS began back 
in October 1993, when a child abduction attempt in LA Mesa Village (military housing) was 
reported to NPS Police. As concerned parents living in La Mesa, we thought that the lengthy 
process to find the culprit was unsatisfactory. Therefore, the authors offered their 
information system (IS) services to the NPS Security Officer to help alleviate this problem. . 
The result of the authors' nearly two year effort was this thesis, and a fully operationally 
relational database program, LEVRAS. In addition, the authors provided extremely 
beneficial suggestions to improve the Security Department's IS. Most of these suggestions 
were funded and acted upon by the NPS Security Officer. A casual visit to the NPS Police 
Headquarters will reveal a dramatic change from past IS operations to include today's 
computer hardware and software technology. 

All of the Naval Postgraduate School Security Department's primary functional 


requirement specifications were met by LEVRAS including: 


(] Capability to input, store, retrieve, update and delete appropriate law 
enforcement and vehicular information. 


() Provide basic and selective query capability for active and archive data. 


[] Provide reports containing accurate and complete vehicular, owner, decal and 
ticket information. 


[! Input and display system data for decal and temporary pass issue. 


[1 Input and display system data for ticket disposition. 
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LEVRAS was installed and tested by the users. The NPS Security Officer and his 
staff gladly accepted LEVRAS as a replacement for their antiquated existing IS, since it 
proved to be a dramatic improvement especially in the areas of query capability and 
archiving old customer data. 

In the first quarter of the Information Technology Management (ITM) curriculum 
at NPS, the /ntroduction to Computer Management (1S-2000) course was instrumental in 
providing the basics of the System Development Methodology (SDM). This methodology 
provided the project team foundation that was a crucial element in making this thesis 
process a success. Acting as an actual software development team, the authors learned many 


lessons along the way. Some of the major lessons learned include: 


Ol The Semantic Object Modeling with Salsa book used in the thesis was 
incomplete. Specifically, the authors did not know how to generate a schema 
using the element known as "data" vice the " ID" element. This was a crucial 
part of making the entire database schema operate properly. Just by a stroke of 
luck, the authors discovered this flaw (after two full days of work), enabling 


them to generate a fully functional schema. 


4 Another two days of work was lost due to the inadvertent omission of a single 
required data field (with approximately a hundred semantic object attributes, this 
type of oversight is easy to make). This caused the entire LEVRAS database 
schema to be re-generated in SAZSA, and required the application development 


in Paradox to start from scratch. 
[] ObjectPal (the fourth generation language provided in Paradox) was much 


harder to program than originally expected. This lengthened the anticipated 


project software development schedule by 25%. 


54 








O The manuals provided with Paradox and after market ObjectPal programming 
books did not clearly present the coding methods needed to program LEVRAS. 
This resulted in code that did not function as expected, and many iterative 


programming re-writes were needed to make the functionalities work properly. 


O Another two days was spent commenting the source code for future maintenance 
or upgrades. The authors did not comment the source code as LEVRAS was 


being developed, but instead went back after the program was fully operational. 


O After developing many LEVRAS menus and forms, the authors discovered that 
similar pushbuttons were located in different places on the different screens. 
This even made the authors confused to the point of vertigo. Realignment of 


these pushbuttons to the exact location on each screen solved this problem. 


[] Leaving this thesis on a positive note, the authors suggest that software 
developers choose project team members carefully. Project team members 
should be compatible both professionally and personally, so that an approach 
such as the Delphi Method can be successfully implemented without any hard 


feelings or grudges. 


Finally, the authors effectively used the knowledge gained in their NPS graduate ITM 
program, by creating a MIS focusing around a relational database. The bottom line result 
of these efforts is improved NPS Security force that can immediately respond to the smallest 
amount of data on military installation intruders. La Mesa Village residents now feel more 


securer knowing that LEVRAS is on their side! 
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APPENDIX A. REQUIREMENTS SPECIFICATION 


This appendix summarizes the top level performance requirements for LEVRAS in 
quantifiable terms. It contains functional and nonfunctional requirements. A functional 
requirement is defined as a detailed description of data inputs, processes, and outputs that 
must be made. A nonfunctional requirement is not a full required function, but rather a 


system characteristic that would enhance the existing functions. 


Primary Functional Requirements 


1. Input, store, retrieve, update and delete appropriate law enforcement and vehicular 
information (complete vehicular, owner, decal, and ticket violation information). 


2. Provide basic and advanced query capability as follows: 
a. Basic - Queries involving entire fields (e.g., last name). 
b. Advanced - Queries involving portions of fields (e.g., last name with the second 
letter of "t"). 


3. Provide reports (hard-copy output) containing accurate and complete venicules owner, 
decal and ticket information on demand. 


4. Input and display system data for decal and temporary pass issue. 


5. Input and display system data for ticket disposition. 


Secondary Functional Requirements 

1. Import data from the COPS system via 5.25 inch floppy disk. 

2. Import data from off-campus sources via 5.25 or 3.5 inch floppy disk or modem (e.g., 
California Law Enforcement Terminal System (CLATS) and Interstate Law Enforcement 
Terminal System (INLETS)). 

3. Be capable of photographic data entry (e.g., a scanning device). 


4. Have anti-virus software protection. 
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5. Generate a daily security violator(s) listing to be distributed to Security Officer and NPS 
gate guards. 


6. Provide password protection in accordance with NPS Security Department regulations. 
7. Have a backup method. The backup medium will be kept physically separate from the 
main secondary storage device, allowing for backups of all data and schema each eight hour 
shift (1.e., three times daily). The backup media should be able to be removed from the 
system for transport or storage away from the system. 


Non-Functional Requirements 


1. Provide a database size to accommodate a minimum of 10,000 vehicles (accompanied 
by all support data such as owner, decal and ticket information). 


2. Provide a response time of a maximum of 30 seconds for basic queries and a maximum 
of 60 seconds for advanced queries. 


3. Update a single vehicle record with a maximum response time of 10 seconds. 


4. Provide a user-friendly interface that an individual with only minimum computer 
experience can effectively use. Also, training will be provided by the authors. 


5. Operate on-line 24-hours a day due to real-time access required by NPS law enforcement. 
6. Provide high quality print capability for reports (hard-copy outputs). 

7. Implement a scheduled periodic and corrective system maintenance plan. 

8. Install a LAN for VIRO and NPS Police. 

9. Use state-of-the-art COTS hardware and software. 


10. Provide a system user's manual to address system administrative procedures. 








APPENDIX B. DATA FLOW DIAGRAMS 


This appendix provides LEVRAS Data Flow Diagrams (DFDs), starting with the 
LEVRAS Decomposition Diagram. The Decomposition Diagram is exploded (decomposed) 
into the overall LEVRAS Context Diagram (First Level). This First Level Diagram is 
exploded into a Second Level Diagram with five processes (PROCESS CUSTOMER 
CHECKIN, PROCESS CUSTOMER CHECKOUT, GENERATE QUERY RESPONSE, 
PROCESS TICKETS, and GENERATE REPORTS). The Second Level Processes are 
further exploded into five primitive Third Level Diagrams with 15 processes (INPUT 
CUSTOMER DATA, MODIFY CUSTOMER DATA, GENERATE VEHICLE DECAL, 
GENERATE TEMPORARY PASS, PROCESS DATA TRANS, ARCHIVE CUSTOMER 
DATA, VALIDATE REQUEST DATA, GENERATE QUERY RESPONSE, INPUT 
TICKET DATA, PROCESS TICKET DISPO, ARCHIVE TICKET DATA, GENERATE 
TICKET REPORT, GENERATE DCL/PASS REPORT, GENERATE CUST/VEH REPORT 
and GENERATE CUSTOM REPORT). LEVRAS External Entities (CUSTOMER, 
SECURITY OFFICER, and POLICEMAN) along with LEVRAS Data Stores (CUSTOMER 
AND VEHICLE DATA, TICKET DATA, and ARCHIVE DATA) are appropriately placed 
throughout LEVRAS DFD Levels, as displayed in the following pages. 
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APPENDIX C. DATA DICTIONARY 


This LEVRAS Data Dictionary contains descriptions of the components of the 
primitive DFDs contained in Appendix B, and as discussed in Chapters HI and IV. This 
appendix will document the external entities, processes, and data stores. Data flows are 
connections between the external entities, processes, and data stores; furthermore, they are 
“common sense" connections and will be presented within the context of the other 


aforementioned DFD components. 
EXTERNAL ENTITIES 


CUSTOMER: An NPS student, staff, or a contractor provides data to the system through 
Process 1 (PROCESS CUSTOMER CHECKIN) and Process 2 (PROCESS CUSTOMER 
CHECKOUT). CUSTOMER information populates and updates two of the data stores 
(CUSTOMER AND VEHICLE DATA and ARCHIVE DATA) to provide current 
information to the SECURITY OFFICER. 


SECURITY OFFICER: The NPS Security Officer (or his staff) represents the initiation of 
control processes in the system to specifically request and receive reports, rather than an 
item to maintain data on. LEVRAS can provide current information to the SECURITY 
OFFICER upon request. The SECURITY OFFICER interfaces with the system through 
Process 3 (GENERATE QUERY RESPONSE), Process 4 (PROCESS TICKETS), and 
Process 5 (GENERATE REPORTS). 


POLICEMAN: An NPS Police Officer represents the input of ticket data, rather than an 
item to maintain data on. The POLICEMAN interfaces with the system only through 
Process 4 (PROCESS TICKET). Ticket information from the POLICEMAN populates and 
updates the TICKET DATA data store. 
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PROCESSES 


1,1P INPUT CUSTOMER DATA: Handles the input of CUSTOMER data during checkin. 
Interfaces with one external entity (CUSTOMER), and one data store (CUSTOMER AND 
VEHICLE DATA). 


1.2P_ MODIFY CUSTOMER DATA: Handles the modification of CUSTOMER data during 
checkin. Interfaces with one external entity (CUSTOMER), and one data store 
(CUSTOMER AND VEHICLE DATA). 


L.3P_GENERATE VEHICLE DECAL: Handles the decal assignment during CUSTOMER 
checkin, when directed by Process 1.1P. Interfaces with one external entity (CUSTOMER), 
and one data store (CUSTOMER AND VEHICLE DATA). 


1.4P_ GENERATE TEMP PASS: Generates a temporary pass during CUSTOMER checkin, 
when directed by Process 1.1P. Interfaces with one external entity (CUSTOMER), and one 
data store (CUSTOMER AND VEHICLE DATA). 


2.1P_ PROCESS DATA TRANS: Processes data transfer information during CUSTOMER 
checkout. Interfaces with two external entities (CUSTOMER and SECURITY OFFICER), 
and one data store (CUSTOMER AND VEHICLE DATA). 


2.2P_ ARCHIVE CUSTOMER DATA: Archives CUSTOMER data during checkout. 
Interfaces with one external entity (SECURITY OFFICER), and one data store (ARCHIVE 
DATA). 


3.1P VALIDATE REQUEST DATA: Validates requested data during query response. 
Interfaces with one external entity (SECURITY OFFICER), and all three data stores 
(CUSTOMER AND VEHICLE DATA, TICKET DATA, and ARCHIVE DATA). 
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3.2P_ GENERATE QUERY RESPONSE: Generates query response when directed by 
process 3.1P. Interfaces with one external entity (SECURITY OFFICER), and no data 


stores. 


4.1P_ INPUT TICKET DATA: Facilitates the input of ticket data for ticket processing. 
Interfaces with one external entity POLICEMAN), and one data store (TICKET DATA). 


4.2P_ PROCESS TICKET DISPO.: Processes ticket disposition. Interfaces with one 
external entity (SECURITY OFFICER), and one data store (TICKET DATA). 


4.3P ARCHIVE TICKET DATA: ‘Archives ticket data at the completion of ticket 
processing as directed by Process 4.2P. Interfaces with no entities, and one data store 
(ARCHIVE DATA). 


5.1P_ GENERATE TICKET REPORT: Generates routine ticket reports. Interfaces with 
one external entity (SECURITY OFFICER), and one data store (TICKET DATA). 


2.2P_ GENERATE DCL/PASS REPORT: Generates routine decal and pass reports. 
Interfaces with one external entity (SECURITY OFFICER), and one data store 
(CUSTOMER AND VEHICLE DATA). 


5,3P_ GENERATE CUST/VEH REPORT: Generates routine CUSTOMER and vehicle 
reports. Interfaces with one external entity (SECURITY OFFICER), and one data store 
(CUSTOMER AND VEHICLE DATA). 


».4P GENERATE CUSTOM REPORT: Generates customized security reports for the 
SECURITY OFFICER. Interfaces with one external entity (SECURITY OFFICER), and all 
three data stores (CUSTOMER AND VEHICLE DATA, TICKET DATA, and ARCHIVE 
DATA). 








DATA STORES 


CUSTOMER AND VEHICLE DATA: Contains a group of attributes concerning 
CUSTOMER and vehicle data (including but not limited to customer's name and address, 


vehicle ID number and model, and insurance policy number). 


TICKET DATA: Contains a group of attributes concerning ticket data (including but not 


limited to ticket number, date, and traffic violation code). 


ARCHIVE DATA: Contains a combination of the data attributes of the two above data 
stores. The active data is contained within CUSTOMER AND VEHICLE DATA and 
TICKET DATA data stores while the inactive data is stored within the ARCHIVE DATA 
data store. Data is stored in the ARCHIVE DATA data store only after being removed from 


one or both of the other two data stores aforementioned. 
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APPENDIX D. SEMANTIC OBJECTS 


This appendix contains printouts of the seven semantic objects designed for the 
LEVRAS database. The attributes, and the cardinality of each attribute, are listed for each 
object. Chapter five of this thesis discusses the process used to construct these data models. 
Descriptions of the attributes and object relationships follow the two pages of semantic 


object models. 
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LEVRAS SEMANTIC OBJECTS 






RegistrationState 






ExpirationDate 14 


EmployeeType 44 


DutyStation 04 


















SMCE 04 


WorkPhoneNumber 04 





“2S DRIVERLICGENSE® 


iD LicenseNumber 14 
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HomeAddress ‘4 Pye 










HomeCty , { 
LicenseState 11 


ExpirationDate 14 


HomedZip 14 


DatabaseEntryDate 44 


InsurancePolicyNumber 14 


RegistationNumber 14 


DecalNumber 
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1D InsurancePolicyNumber 14 


eINSURA 


1.1 





TicketNumber 14 


Licens ePiateNumber 
1.1 InsuranceCompanyName 14 


1.4 ExpirationDate 


1.4 


CUSTOMER 14 


4.1 
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LEVRAS SEMANTIC OBJECTS 
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APPENDIX E. DATABASE TABLES 


This appendix contains the LEVRAS database tables which were created in the 
schema generation process. Chapter five of this thesis discusses generation of database 
schema, and the semantic modelling steps that occur prior to it. One database table was 


created for each of the LEVRAS semantic objects, which can be found in Appendix F. 
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Attribute Report 
Album: LEVRAS.ALB 





BaseCounDate Type: Simple Value 
Profile: BaseCourtDate 
Contained in: TICKET 
Caption: CrtDate 
Description: BaseCourtDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 

Format: DD/MMIYY 
initial Value: 





BaseDisposition Type: Simple Value 
Profile: BaseDisposition 
Contained in: TICKET 
Caption: Dispostn 
Description: BaseDisposition 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 30 
Format: Warning 
Initial Value: 





BaseDispositionDate Type: Simple Value 
Profile: BaseDispositionDate 
Contained in: TICKET 
Caption: DispDt 
Description: BaseDispositionDate 
ID Status: None 
Minimum Required: 0 
Maximum Ailowed: 1 
Value Type: Date 
Length: 
Format: MM/DDIYY 
Initial Value: 





BaseJudgeName Type: Simple Vaiue 
Profile: BaseJudgeName 
Contained in: TICKET 
Caption: JudgeName 
Description: BaseJudgeName 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: McGibbon 
Initial Value: 
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Attribute Report 
Album: LEVRAS.ALB 





Curric/Staff 


Type: Simpie Value 
Profile: Curric/Staff 
Contained in: CUSTOMER 
Caption: Curric/Staff 
Description: Curric/StaffCode 
iD Status: None 

Minimum Required: 0 
Maximum Allowed: 1 
Vaiue Type: Text 

Length: 3 

Format: 123 

Initial Value: 





CUSTOMER 


Type: Object Link 
Profile. CUSTOMER 
Contained in: DECAL 
Caption: CUSTOMER 
Description: CUSTOMER 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 





CUSTOMER 


Type: Object Link 

Profile: CUSTOMER 
Contained in: INSURANCE 
Caption: CUSTOMER 
Description: CUSTOMER 
ID Status: None 

Minimum Required: 1 
Maximum Allowed: 1 





CUSTOMER 


Type: Object Link 
Profile: CUSTOMER 
Contained in: TICKET 
Caption: CUSTOMER 
Description: CUSTOMER 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 





CUSTOMER 


Type: Object Link 

Profile: CUSTOMER 

Contained in: DRIVERLICENSE 
Caption: CUSTOMER 
Description: CUSTOMER 

ID Status: None 

Minimum Required: 1 

Maximum Allowed: 1 
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Attribute Report 
Album: LEVRAS.ALB 


ee 


CUSTOMER Type: Object Link 
Profile: CUSTOMER 
Contained in: VEHICLE 
Caption: CUSTOMER . 
Description: CUSTOMER 
1D Status: None 
Minimum Required: 1 
Maximum Allowed: 1 


ne NR 


CUSTOMER Type: Object Link 
Profile: CUSTOMER 
Contained in: REGISTRATION 
Caption: CUSTOMER 
Description: CUSTOMER 
ID Status: None 
Minimum Required: 1 
Maximum Aliowed: 1 


rere cs rl CS TT 


DatabaseEntryDate Type: Simple Value 
Profile: TransactionDate 
Contained in: CUSTOMER 
Caption: DatabaseEnrtyDate 
Description: DatabaseEntryDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 
Format: MM/DD/YY 
Initiat Value: 


I 


DECAL Type: Object Link 
Profite: DECAL 
Contained in: VEHICLE 
Caption: DECAL 
Description: DECAL 
1D Status: None 
Minimum Required: 1 
Maximum Aliowed: 1 


I 


DECAL Type: Object Link 
Profile: DECAL 

Contained in: CUSTOMER 
Caption: DECAL 
Description: DECALINFO 
iD Status: None 
Minimum Required: 1 
Maximum Allowed: N (No Limit) 


rr nr TR EtG 
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Attribute Report 
Album: LEVRAS.ALB 





DecalColor Type: Simple Value 
Profiie: DecalColor 
Contained in: DECAL 
Caption: DciCir 
Description: DecaiColor 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Vaiue Type: Text 
Length: 5 
Format: Green 
Initial Value: 





DecalExpirationMonth Type: Simple Value 
Profile: DecalExpirationMonth 
Contained in: DECAL. 
Caption: DclExpMo 
Description: DecalExpirationMonth 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 4 
Value Type: Text 
Length: 2 
Format: 04 
initial Vatue: 





DecalExpirationYear § Type: Simple Value 
Profile: DecalExpirationYear 
Contained in: DECAL 
Caption: DclExpYr 
Description: DecalExpirationYear 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: 95 
initial Vatue: 





DecalissueDate Type: Simple Value 
Profile: DecalissueDate 
Contained in: DECAL 
Caption: DcilssueDt 
Description: DecalissueDate 
iD Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 

Format: MM/DDIYY 
Initial Value: 








Attribute Report 
Album: LEVRAS.ALB 





DecalNumber Type: Simple Value 
Profile: DecalNumber 
Contained in: CUSTOMER 
Caption: Dct# 

Description: DecaiNumber 
1D Status: None 

Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 

Length: 6 

Format: ABC123 

initial Value: 


DecalNumber Type: Simple Vaiue 
Profile: DecalNumber 
Contained in: DECAL 
Caption: DOci# 
Description: DecalNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 4 
Value Type: Text 
Length: 6 
Format: ABC123 
Initial Value: 


DRIVERLICENSE Type: Object Link 
Profile: DRIVERLICENSE 
Contained in: CUSTOMER 
Caption: DRIVER LICENSE 
Description: DRIVERLICENSE 
ID Status: None 
Minimum Required: 4 
Maximum Allowed: 1 





DutyStation Type: Simple Vaiue 
Profile: DutyStation 
Contained in: CUSTOMER 
Caption: DutyStation 
Description: DutyStation 
ID Status: None 
Minimum Required: 0 
Maximum Aliowed: 1 
Value Type: Text 
Length: 10 
Format: NPS 
initial Value: 
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Attribute Report 
Album: LEVRAS.ALB 





EmployeeType Type: Simple Value 
Profile: EmployeeType 
Contained in: CUSTOMER 
Caption: EmployeeType 
Description: EmployeeType 
iD Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: ABCDEFGHIJ 
Initial Value: 





ExpirationDate Type: Simple Value 
Profile: ExpirationDate 
Contained in: REGISTRATION 
Caption: RegExpDt 
Description: RegistrationExpDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 
Format: MM/DD/YY 
Initial Value: 





ExpirationDate Type: Simple Value 
Profile: ExpirationDate 
Contained in: INSURANCE 
Caption: ExpDt 
Description: ExpirationDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 
Format: MM/DDIYY 
initial Value: 





ExpirationDate Type: Simple Value 
Profile: ExpirationDate 
Contained in: DRIVERLICENSE 
Caption: ExpDt 
Description: LicenseExpirationDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 
Format: MM/DD/YY 
initial Value: 
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Attribute Report 
Aibum: LEVRAS.ALB 





Faculty Type: Simple Value 
Profile: Faculty 
Contained in: CUSTOMER 
Caption: Faculty 
Description: FacultyDepartment 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: AB 
Initial Value: 





FirstName Type: Simple Value 
Profile: FirstName 
Contained in: CUSTOMER 
Caption: FirstName 
Description: FirstName 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: ABCDEFGHIJ 
Initial Value: 





Grade Type: Simple Value 
Profile: Grade 
Contained in: CUSTOMER 
Caption: Grade 
Description: EmployeeGrade 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 4 
Format: GS13 
initial Value: 





HomeAddress Type: Simple Value 
Profile: HomeAddress 
Contained in: CUSTOMER 
Caption: HomeAddress 
Description: StreetNumberAndStreetName 
iD Status: None 
Minimum Required: 1 
Maximum Aflowed: 1 
Value Type: Text 
Length: 30 
Format: 123456Abcdefghijkimnoparstuvwxyz 
initial Value: 
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Attribute Report 
Album: LEVRAS.ALB 





HomeCity Type: Simple Value 
Profile: City 
Contained in: CUSTOMER 
Caption: City 
Description: City 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 17 
Format: ABCDEFGHIJKLMNOPQ 
Initial Value: 





HomePhone Type: Simple Value 
Profile: HomePhone 
Contained in. CUSTOMER 
Caption: HomePhone 
Description: HomePhoneNumber 
ID Status: None 
Minimum Required: 4 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: 4086551234 
initial Value: 





HomeState Type: Simple Value 
Profile: State 
Contained in: CUSTOMER 
Caption: State 
Description: 2DigitStateCode 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: CA 
Initial Value: 





HomeZip Type: Simple Vaiue 
Profile: Zip 
Contained in: CUSTOMER 
Caption: HomeZipCode 
Description: HomeZipCode 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 5 
Format: 93940 
Initial Vatue: 
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Attribute Report 
Album: LEVRAS.ALB 


ee eee TTT Te 


INSURANCE Type: Object Link 
Profile: INSURANCE 
Contained in: CUSTOMER 
Caption: INSURANCE 
Description: INSURANCE 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: N (No Limit) 


a 


INSURANCE Type: Object Link 
Profile: INSURANCE 
Contained in: CUSTOMER 
Caption: INSURANCE 
Description: INSURANCE 
iD Status: None 
Minimum Required: 1 
Maximum Allowed: 1 





insuranceCompanyNam Type: Simple Value 
e rrofile: insuranceCompanyName 
Contained in: INSURANCE 
Caption: InsCo 
Description: InsuranceCompanyName 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 15 
Format: Abcdefghijkimno 
Initial Value: 


nr A ED 


InsurancePolicyNumber Type: Simple Vatue 
Profile: InsurancePolicyNumber 
Contained in: CUSTOMER 
Caption: insPott 
Description: insurancePolicyNumber 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 20 
Format: Abcdefghij0123456789 
Initial Value: 


tree apy zt rea Gc SS ON 


insurancePolicyNumber Type: Simple Value 
Profile: insurancePolicyNumber 
Contained in: INSURANCE 
Caption: insPol# 
Description: InsurancePolicyNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 20 
Format: Abcdefghij0123456789 
initial Value: 
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LastName Type: Simple Value 
Profile: LastName 
Contained in: CUSTOMER 
Caption: LastName 
Description: FisrtName 
iD Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 15 
Format: ABCDEFGHIJKLMNO 
Initial Value: 





LicenseNumber Type: Simple Value 
Profile: LicenseNumber 
Contained in: DRIVERLICENSE 
Caption: License# 
Description: DriverLicenseNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 1 
Vaiue Type: Text 
Length: 10 
Format: C228123ABD 
initial Value: 





LicenseNumber Type: Simple Value 
Profile: LicenseNumber 
Contained in. CUSTOMER 
Caption: License# 
Description: DriverLicenseNumber 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Vaiue Type: Text 
Length: 10 
Format: C228123ABD 
Initial Value: 





LicensePlateNumber Type: Simple Value 
Profile: LicensePlateNumber_786434 
Contained in: CUSTOMER 
Caption: Piate# 
Description: LicensePlateNumber 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: ABCDE12345 
initial Value: 
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Attribute Report 
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LicensePiateNumber Type: Simple Value 
Profile: LicensePlateNumber_ 786434 
Contained in: VEHICLE 
Caption: Plate#¥ 
Description: LicensePlateNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: ABCDE12345 
initial Value: 





LicensePlateState Type: Simple Vaiue 
Profile: LicensePiateState 
Contained in: VEHICLE 
Caption: PlateST 
Description: LicensePlateState 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: MA 
initial Value: 





LicenseState Type: Simple Value 
Profile: LicenseState 
Contained in: DRIVERLICENSE 
Caption: LicenseST 
Description: 2DigitStateCode 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: CA 
initial Value: 





Middielnitial Type: Simple Value 
Profile: Middleinitia! 
Contained in: CUSTOMER 
Caption: Ml 
Description: Middleinitial 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 1 
Format: A 
Initial Value: 
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Points Type: Simple Value 
Profile: Points | 
Contained in: TICKET 
Caption: Pt 
Description: DrivingPoints 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: 12 
Initiat Value: 





PolicemanName Type: Simpie Vaiue 
Profile: TicketOfficerName 
Contained in: TICKET 
Caption: PolicemanName 
Description: PolicemanName 
iD Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: Jones 
Initial Value: 





Rank Type: Simple Value 
Profile: Rank 
Contained in: CUSTOMER 
Caption: Rank 
Description: MilitaryRank 
1D Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 3 
Format: E02 
initial Value: 





RegistationNumber Type: Simple Value 
Profile: RegistationNumber 
Contained in: CUSTOMER 
Caption: Reg# 
Description: RegistationNumber 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: ABCDE12345 
initial Value: 
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Attribute Report 
Album: LEVRAS.ALB 
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RegistationNumber Type: Simple Value 
Profile: RegistationNumber 
Contained in: REGISTRATION 
Caption: Reg# 
Description: RegistationNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format ABCDE12345 
Initial Value: 





REGISTRATION Type: Object Link 
Profile: REGISTRATION 
Contained in: VEHICLE 
Caption: REGISTRATION 
Description: REGISTRATION 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 





REGISTRATION Type: Object Link 
Profile: REGISTRATION 
Contained in: CUSTOMER 
Caption: REGISTRATION 
Description: REGISTRATION 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: N (No Limit) 
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RegistrationState Type: Simple Value 
Profile: RegistrationState 
Contained in: REGISTRATION 
Caption: RegST 
Description: 2DigitStateCode 
1D Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: CA 
initial Vatue: 
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Sex Type: Simple Value 
Profile: Sex 
Contained in: CUSTOMER 
Caption: Sex 
Description: MaleOrFemaie 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Vaiue Type: Text 
Length: 6 
Format: Abcdef 
initial Value: 
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SMC# Type: Simple Value 
Profile: SMC# 
Contained in: CUSTOMER 
Caption: SMC# 
Description: StudentPostOfficeBox# 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 4 
Format: 1234 
initial Value: 





SocialSecurityNumber Type: Simple Vaiue 
Profile: SocialSecurityNumber 
Contained in: CUSTOMER 
Caption: SSN 
Description: SocialSecurityNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 9 
Format: 141223333 
Initial Value: 





TICKET Type: Object Link 
Profile: TICKET 
Contained in: CUSTOMER 
Caption: TICKET 
Description: TICKET 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: N (No Limit) 


TICKET Type: Object Link 
Profile: TICKET 
Contained in: VEHICLE 
Caption: TICKET 
Description: TICKET 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: N (No Limit) 





TicketNumber Type: Simple Value 
Profile: TicketNumber 
Contained in: TICKET 
Caption: TKT# 
Description: TicketNumber 
ID Status: Unique 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 9 
Format: A12345678 
Initial Value: 
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TicketNumpber Type: Simple Vaiue 
Profile: TicketNumber | 
Contained in: CUSTOMER 
Caption: TKT# 
Description: TicketNumber 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 9 
Format: A12345678 
Initial Value: 
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TransactionDate Type: Simple Value 
Profite: TransactionDate 
Contained in: TICKET 
Caption: TmDt | 
Description: TransactionDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Date 
Length: 

Format: MM/DD/YY 
Initial Value: 


ven 


VEHICLE Type: Object Link 
Profile: VEHICLE 
Contained in: CUSTOMER 
Caption: VEHICLE 
Description: VEHICLE 
{D Status: None 
Minimum Required: 1 
Maximum Allowed: N (No Limit) 


I 


. VEHICLE Type: Object Link 
Profile: VEHICLE 
Contained in: DECAL 
Caption: VEHICLE 
Description: VEHICLE 
1D Status: None 
Minimum Required: 1 
Maximum Allowed: 1 


I 


VEHICLE Type: Object Link 
Profile: VEHICLE 
Contained in: REGISTRATION 
Caption: VEHICLE 
Description: VEHICLE 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
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Attribute Report 
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VEHICLE Type: Object Link 
Profile: VEHICLE 
Contained in: INSURANCE 
Caption: VEHICLE 
Description: VEHICLE 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: N (No Limit) 





VERICLE Type: Object Link 
Profile: VEHICLE 
Contained in: TICKET 
Caption: CUSTOMER 
Description: CUSTOMER 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 


LL 


VehicieColor Type: Simple Value 
Profile: VehicleColor 
Contained in: VEHICLE 
Caption: VehColor 
Description: VehicleColor 
ID Status: None 
Minimum Required: 4 
Maximum Allowed: 1 
Value Type: Text 
Length: 7 
Format: ABCDEFG 
Initial Value: 


i 


VehicleldentNumber § Type: Simple Value 
Profile: VehicieldentNumber 
Contained in: VEHICLE 
Caption: VIN 
Description: VehicteldentificationNumber 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 20 
Format: 
tnitial Value: 


ER 


VehicieMake Type: Simple Value 
Profite: VehicleMake 
Contained in: VEHICLE 
Caption: Make 
Description: VehicleMake 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 5 
Format: ABCDE 
Initia! Value: 


a 


i 
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VehicleType Type: Simple Value 
Profile: VehicleType 
Contained in: VEHICLE 
Caption: Model 
Description: VehicleType 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 11 
Format: ABCDEFGHIJK 
initial Value: 





VehicleYear Type: Simple Vaiue 
Profile: VehicleYear 
Contained in: VEHICLE 
Caption: Year 
Description: VehicleYear 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 1 
Value Type: Text 
Length: 2 
Format: 95 
Initia! Value: 


ViolatlonCode Type: Simple Value 
Profile: ViolationCode 
Contained in: TICKET 
Caption: VioCd 
Description: ViolationCode 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 4 
Value Type: Text 
Length: 2 
Format: 23 ‘ 
Initial Value: 


ViolationDate Type: Simple Value 
Profile: ViolationDate 
Contained in: TICKET 
Caption: VioDate 
Description: ViolationDate 
ID Status: None 
Minimum Required: 1 
Maximum Allowed: 4 
Value Type: Date 
Length: 

Format: MM/DDIYY 
Initial Value: 





WorkPhoneNumber Type: Simple Value 
Profite: WorkPhoneNumber 
Contained in: CUSTOMER 
Caption: WorkPhoneNumber 
Description: WorkPhoneNumber 
ID Status: None 
Minimum Required: 0 
Maximum Allowed: 1 
Value Type: Text 
Length: 10 
Format: 4086561234 
Initial Value: 
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Relationshir . 
Table Type Mandatory Related Table Foreign Key Relationships 
CUSTOMER 4:N Yes REGISTRA SocialSecurityNumber matches SocialSecurityNum 
ber_FK1 
1.N Yes VEHICLE SocialSecurityNumber matches Socia!SecurityNum 
a ber FK3 
1:N Yes DECAL SocialSecurityNumber matches SocialSecurityNum 
ber_FK4 
O.N No TICKET SocialSecurityNumber matches SocialSecurityNum 
ber FK6 
1:1 Yes ORIVERL! SocialSecurityNumber matches SocialSecurityNum 
ber_FK8 
4:N Yes INSURANC SocialSecurityNumber matches SocialSecurityNum 
ber_FK9 
DECAL 44 Yes CUSTOMER SociaiSecurityNumber_FK4 matches SocialSecurity 
Number ; 
71 Yes | VEHICLE VE_LicensePlateNumber_ 
FK5 matches LicensePlateNumber 
DRIVERLI 1:4 Yes CUSTOMER SocialSecurityNumber_FK8 matches SocialSecurity 
Number 
INSURANC 4.1 Yes CUSTOMER SocialSecurityNumber_FK9 matches SociaiSecurity 
: Number . 
1.1 Yes VEHICLE V_LicensePiateNumber_FK10 matches LicensePlat 
eNumber 
REGISTRA 14 Yes CUSTOMER SocialSecurityNumber_FK1 matches SocialSecurity 
Number 
44 - Yes VEHICLE VE_LicensePlateNumber_ 
FK2 matches LicensePlateNumber 
TICKET 144 Yes CUSTOMER SocialSecurityNumber_FK6 matches SocialSecurity 
° Number 
0.1 No VEHICLE VE_LicensePlateNumber_ 
FK7 matches LicensePlateNumber 
VEHICLE 4.1 Yes REGISTRA LicensePlateNumber matches VE_ 
LicensePiateNumber_FK2 
4:1 Yes CUSTOMER SocialSecurityNumber_FK3 matches SocialSecurity 
Number 
4 Yes DECAL LicensePlateNumber matches VE_ 
LicensePlateNumber_FK5 
‘0.N No TICKET LicensePlateNumber matches VE_ 
LicensePlateNumber_FK7 
14 Yes INSURANC LicensePlateNumber matches V_ 
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CUSTOMER Table 


DBMS Type: PARADOX for Windows/DOS 4.0+ 
Source Object or Attribute: CUSTOMER Object 





Null 
Column Name Value Type Length Allowed Object Attribute Name index 
Curric/Staff A 3 Yes CUSTOMER. Curric/Staff 
DatabaseEntryDate D No ee ER.DatabaseEntry 
ate 
DecalNumber A 6 No CUSTOMER.DecalNumber 
DutyStation A 10 Yes CUSTOMER. DutyStation 
EmployeeType A 10 No CUSTOMER.EmployeeType 
Faculty A 2 Yes CUSTOMER Faculty 
FirstName A 10 No CUSTOMER.FirstName 
Grade A 4 No CUSTOMER.Grade 
HomeAddress A 30 No CUSTOMER. HomeAddress 
HomeCity A af No CUSTOMER. HomeCity 
HomePhone A 10 No CUSTOMER. HomePhone 
HomeState A 2 No CUSTOMER. HomeState 
HomeZip A 5 No CUSTOMER.HomeZip 
InsurancePolicyNumber A 20 No CUSTOMER. InsurancePolicy 
Number 
LastName A 15 No CUSTOMER.LastName 
LicenseNumber A 10 No CUSTOMER. LicenseNumber 
LicensePiateNumber A 10 No ad la als 
mber 
Middlelnitial A 4 Yes CUSTOMER. Middlelinitial 
Rank A 3 Yes CUSTOMER. Rank 
RegistationNumber A 10 No soo ener ven j 
er 
Sex A 6 No CUSTOMER. Sex 
SMC# A 4 Yes CUSTOMER.SMC# 
SociaiSecurityNumber A 9 No oe OMER.SocialSecurityN PrimaryKey 
umber 
TicketNumber A 9 No CUSTOMER. TicketNumber 
WorkPhoneNumber A 10 Yes erect e ene 
mber 
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LEVRAS DATABASE 
Table Report 
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VEHICLE Table 


DBMS Type: PARADOX for Windows/DOS 4.0+ 
Source Object or Attribute: VEHICLE Object 


Column Name Value Type 
LicensePlateNumber A 


LicensePlateState 
SocialSecurityNumber_FK3 
VehicleColor 
VehicleidentNumber 


VehicileMake 
VehicleType 
VehicleYear 


PrPr>r>r YP PrYrrp 


Null 

Length Allowed Object Attribute Name index 

10 No VEHICLE.LicensePlateNumb PrimaryKey 
er 

2 No VEHICLE. LicensePiateState 

9 No ForeignKey 

7 No VEHICLE. VehicleColor 

20 No VEHICLE. VehicleldentNumb 
er 

5 No VEHICLE. VehicleMake 

11 No VEHICLE. VehicleType 

2 No VEHICLE. VehicleYear 





LEVRAS DATABASE 


Table Report 
Album: LEVRAS.ALB 





DRIVERLI Table 





DBMS Type: PARADOX for Windows/DOS 4.0+ 


Source Object or Attribute: DRIVERLICENSE Object 





Column Name 
ExpirationDate 


LicenseNumber 
LicenseState 


SociaiSecurityNumber_FK8 


Value Type 
D 


A 


A 


Null 
Length Allowed Object Attribute Name Index 
No DRIVERLICENSE. 
ExpirationDate 
10 No DRIVERLICENSE. PrimaryKey 
LicenseNumber 
2 No DRIVERLICENSE. 
LicenseState 
9 No ForeignKey 
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LEVRAS DATABASE 


Table Report 
Album: LEVRAS.ALB 





REGISTRA Table 


DBMS Type: PARADOX for Windows/DOS 4.0+ 
Source Object or Attribute: REGISTRATION Object 





Null 

Column Name Value Type Length Allowed Object Attribute Name index 
ExpirationDate D No REGISTRATION. 

ExpirationDate 
RegistationNumber A 10 No REGISTRATION. PrimaryKey 

RegistationNumber 
RegistrationState A 2 No REGISTRATION. 

RegistrationState 
SocialSecurityNumber_FK1 A No ForeignKey 
VE_LicensePlateNumber_FK2 A 10 Yes Foreignkey 
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Table Report 
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INSURANC Table 


DBMS Type: PARADOX for Windows/DOS 4.0+ 
Source Object or Attribute: INSURANCE Object 


Nuil 

Column Name Value Type Length Allowed Object Attribute Name index 
ExpirationDate D No INSURANCE. ExpirationDate 
InsuranceCompanyName A 15 No INSURANCE. InsuranceComp 

anyName 
InsurancePolicyNumber A 20 No INSURANCE. InsurancePolicy PrimaryKey 

Number 
SocialSecurityNumber_FK9 A 9 No ForeignKey 
V_LicensePlateNumber_FK10 A 10 Yes ForeignKey 
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LEVRAS DATABASE 








Table Report 
Album: LEVRAS.ALB 
DECAL Table 
DBMS Type: PARADOX for Windows/DOS 4.0+ 
Source Object or Attribute: DECAL Object 
Null 
Column Name Value Type Length Allowed Object Attribute Name index 
DecalColor A 5 No DECAL.DecaiColor 
DecalExpirationMonth A 2 No DECAL..DecalExpirationMont 
h 
DecalExpirationYear A 2 No DECAL. DecalExpirationYear 
DecalissueDate D No DECAL.DecallssueDate 
DecaiNumber A 6 No DECAL. DecalNumber PrimaryKey 
SocialSecurityNumber_FK4 A 9 No ForeignKey 
VE_LicensePlateNumber_FK5 A 10 Yes ForeignKey 
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LEVRAS DATABASE 


Table Report 
Album: LEVRAS.ALB 
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TICKET Table 


DBMS Type: PARADOX for Windows/DOS 4.0+ 
Source Object or Attribute: TICKET Object 


Null 
Column Name Value Type Length Allowed Object Attribute Name Index 
BaseCourtDate D No TICKET. BaseCourtDate 
BaseDisposition A 30 Yes TICKET. BaseDisposition 
BaseDispositionDate D Yes TICKET. BaseDispositionDate 
BaseJudgeName A 10 Yes TICKET. BaseJudgeName 
Points A 2 Yes TICKET. Points 
PolicemanName A 10 No TICKET. PolicemanName 
SocialSecurityNumber_FK6 A 9 No Foreignkey 
TicketNumber A 9 No TICKET. TicketNumber PrimaryKey 
TransactionDate D No TICKET. TransactionDate 
VE_LicensePlateNumber_FK7 A 10 Yes ForeignKey 
ViolationCode A 2 No TICKET. ViolationCode 
ViolationDate D No TICKET. ViolationDate 
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APPENDIX F. APPLICATION MENUS 


This appendix contains copies of the LEVRAS Application Menus. Included are the 
WELCOME TO LEVRAS introduction screen, and the MfMAIN MENU. The welcome screen 
is shown upon entering the LEVRAS program, and provides title slide type information. The 
Main Menu then allows LEVRAS users to proceed to the desired application in order to 


conduct required business. 
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APPENDIX G. APPLICATION INPUT FORMS 


This appendix contains examples of all of the LEVRAS Data Input Forms which 
can be used in the system. In addition, a copy of the Ticket Administrator screen is also 
included. The construction of these forms 1s discussed in chapter five of this thesis, and 
instructions on their use are contained in the LEVRAS User's Manual (see Appendix J of 
this thesis). 
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APPENDIX H. APPLICATION OUTPUT REPORTS 


This appendix contains examples of the following LEVRAS application output 
reports: Customer and Vehicle Status Report, Decal Status Report, Ticket Status Report, 
and a Customized Report (designed per NPS Security Officer direction). These reports are 
printed out routinely to provide supervisory information concerning LEVRAS operations. 
In addition, the Customized Report can be reformatted anytime to maximize the quality of 


information provided to the NPS Security Officer. The construction of these reports is 


discussed in chapter five of this thesis. Instructions on the use of these reports is contained 


in the LEVRAS User's Manual (see Appendix J). 





NAVAL POSTGRADUATE SCHOOL CUSTOMER VEHICLE REPORT 


SSN: Duty Station : 
Last Name : SMC# : ope ca 
First Name : Work Phone : 
Middle Initial : ——— Curric/Staff : eo 
Rank : O3.«d Home Phone : Pe aa 
Employee Type : [sti=sSCY Database Entry Date : 
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NAVAL POSTGRADUATE SCHOOL CUSTOMER DECAL REPORT 


SSN: Duty Station : 
Last Name : SMC# : fs 
First Name: Work Phone : 
Middle Initial : iC IS eat [ 
Rank : o3.St~SY Home Phone : od 
Employee Type : eo el Database Entry Date : 





AA2770 09 95 


AB2770 09 95 | 





NAVAL POSTGRADUATE SCHOOL CUSTOMER TICKET VIOLATION REPORT 





SSN: Duty Station : 
Last Name : Sues Le tou dl 
First Name : one r none [ 
Middle Initial : eae eee 


Rank: es] Homerhone: [id 
Employee Type : C..«d DatabaseEntryDate: [ 
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5560 
NPS (44) 
Saturday, May 13, 1995 


MEMORANDUM 


From: Greg Caughran, Security Officer, Code 44 
To: MCGIBBON, HENRY, M, 026~-44-0020, NPS, 36 


Subj: TEMPORARY SUSPENSION OF DRIVING PRIVILEGES 


Ref: (a) NAVPGSCOLINST 5560.5 
(b) OPNAVINST 11200.5C 


Encl: (1) Letter of Acknowledgement of Temporary Suspension of Driving Privileges 


1. In accordance with references (a) and (b), you are hereby notified that your 
driving privileges on the Naval Postgraduate School and temporarily suspended, 
(and two points have been assessed to your driving priviliges, effective 
immediately. The suspension is issued because you failed to acknowledge the 
following citation number(s) on the following dates within the three working days as 





specified on the citation(s): 
10085380 12/12/95 
40085383 5/7195 


During this suspension period, you are not to drive any privately owned motor vehicles 
on NPS property, including motorcycles and mopeds. 


2. This suspension is mandatory. An exception may be granted only by a request for 
court appearance with the traffic hearing officer. 


3. You are to report to the Security Department and submit enclosure (1) no later than 
FIVE DAYS after receipt of this later. At this time you driving privileges will be 
suspended for 10 WORKING DAYS from the date you reportto the Security Department. 
Point of contact is Ms. Marilyn Owens (Traffic Administrator) at extension 2556. 


Greg C. Caughran 












Tuesday, May 


Lather ta 
pola th teetaechd 


Sample Query Output Report 











APPENDIX I. PROGRAM SCRIPTS 


This appendix contains the unique LEVRAS Program Scripts. These program scripts 
are copies of the actual lines of source code, using the Paradox ObjectPal programming 
language. The functions of the source code include the pushbutton execution of commands 
presented on the LEVRAS forms and menus. The source code also displays the linkage 
between the various LEVRAS data input forms and menus. Chapter five of this thesis 
contains information on program script generation. The LEVRAS User's Manual, Chapter 
V., contained in Appendix J, refers maintainers to Paradox publications if the need to modify 


the source code arises. 
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Page 1: BEGIN: :#Scriptl::run 


; COMMENT: THE PROGRAM SCRIPT FILE ALLOWS THE USER TO PUSH 
: THE SCRIPT BUTTON TO START THE LEVRAS PROGRAM. 


method run(var eventinfo Event) 


;declares userInput String and Form to be used to provide 
jeredit to LEVRAS designers and developers in a UserInput 
;information box, and then takes the user to the first form 
; (welcome) of the LEVRAS program (after pushing the script 
;pushbutton on the Paradox speed bar)." 


var 
userInput String 
formVar Form 
endVar 


ugerInput = " LAW ENFORCEMENT VEHICLE 
REGISTRATION ADMINISTRATION 
SYSTEM (LEVRAS) 
designed & developed by: 


CDR Mark S. Nault, USN 
& 

LT Henry M. McGibbon, USN" 
userInput.View("About LEVRAS") 
formVar. open ("welcome") 
close () 


endmethod 


Page 1: WELCOME: :#Button7: :pushButton* 


;COMMENT: WELCOME FORM ADVANCES TO MAIN MENU FORM 
method pushButton(var eventInfo Event) 
;declares the Main Menu form 

var 


mainForm Form; declaring MainMenu form. 
endVar 


jopens the Main Menu form and closes the Welcome 
; form 


mainForm.open("mainmenu"); opens Main Menu. 
mainForm. show () 
close () 


endmethod 
124 








Page 1: MAINMENU: :#Buttoné: :pushButton* 


; COMMENT: ADVANCES THE MAIN MENU FORM TO 
; CUSTOMER INFORMATION FORM 


method pushButton(var eventInfo Event) 
;declares Customer table and form 
var 
custTbl Table 


custForm Form 
endVar 


;opens Customer Information form and closes Main Menu 
; form 
f 


custTbl.attach ("Customer. DB") 


;ensures that only one user writes to a table in a 
j7IMltiuser mode 


if not lock(custTbl, "Write", "customer.db", "Write") then 
endif 

custForm. open ("Customer") 

custForm. show () 


close () 


endmethod 


Page 1: MAINMENU: :#Button7: :pushButton* 


; COMMENT: DEPARTS LEVRAS PROGRAM ALTOGETHER 
; FROM THE MAIN MENU 


method pushButton(var eventInfo Event) 


;Closes the Main Menu and leaves the 
;LEVRAS program 


close () 


endmethod 
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Page 1: MAINMENU: : #Buttonl10: :pushButton* 


; COMMENT: INSTRUCTIONS ON HOW TO PERFORM QUERIES ALONG WITH 
; AN EXAMPLE OF AN EXECUTED QUERY (CUSTOMER. OBE) 
; AND ITS RESULTS (PRIVATE.DB) . 


method pushButton(var eventInfo Event) 


;@eclares contextHelp String for info 
jboxes and tv TableView for query 


var 
contextHelp String 
tv TableView 
endVar 


beep () 
;quote used name used in info box 


contextHelp = "Queries can be performed 
by selecting a pre-made *.QBE file. 
Select File->Open->Query. Choose 
pre-made query fm Select File box. 

Push Lightning Bolt on Speedbar 

to execute query. Further Questions? 
Refer to LEVRAS User's Manual." 
contexthelp.view("LEVRAS QUERIES") 


beep {) 
iquote used and name of info box 


contextHelp = "An example of a 

successful Customer.QBE query 

is to follow. Ensure to select 

Close in the top left 

corner of the Priv: answer.DB 

window after viewing." 
contexthelp.view("LEVRAS QUERY EXCUTION EX.") 


;executes customer.qbe query and stores answer 
;in a table called :priv:anewer.db. If the 
;query has execution errors, a magstop box 
;will appear stating that a query execution 
;error has occured. 


beep () 

if executeQBEFile("customer.qhe", ":priv:answer.db") then 
tv.open(":priv:answer.db") 

else megStop("QUERY EXECUTION ERROR", "The query 

example called CUSTOMER.QBE was 

not executed! Select 

CUSTOMER.QBE and try again!") 


enar£t 


endmethod 











Page 1: B:\MAINMENU: :#Button21: :pushButton* 


; COMMENT: ADVANCES THE MAIN MENU FORM TO 
: PROCESS TICKET FORM 


method pushButton(var eventiInfo Event) 
;declares Process Ticket form 


var 

procForm Form 

tcOne, teTwo, tcThree, TcFour TCursor 
endVar 


;Write lock is enforced if another user tries to access 
jwhile being used 


tcOne. open ("Customer") 

teTwo.open ("Decal") 

teThree.open("Vehicle") 

tcFour.open("Ticket") 

lock (tcOne, "Write", tcTwo, "Write", 
teThree, "Write", tcFour, "Write") 


;opens Process Ticket form and closes the Main Menu 
; form 

procForm. open ("processt") 

procForm. show () 


close {) 


endmethod 
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Page 1: MAINMENU: : #Button36: :pushButton* 


; COMMENT: MAIN MENU FORM CONTEXT HELP STRING 
method pushButton(var eventInfo Event) 
;declares contextHelp string for info box 
var | 
contextHelp String 


endVar 


;displays quoted info (below) and names 
;the box LEVRAS HELP 


beep () 

contextHelp = "Refer to LEVRAS User's Manual 
for help and/or push F1." 
contexthelp.view("LEVRAS HELP") 


endmethod 


Page 1: MAINMENU: :#Button37: :pushButton* 


; COMMENT: ADVANCES THE MAIN MENU FORM TO 
: LEVRAS REPORT FORM 


method pushButton(var eventiInfo Event) 
;declares Report form 
var 
repoForm Form 


endVar 


jopens Report form and then closes 
the Main Menu form 


repoForm. open ("reports") 
repoForm. show () 


close () 


endmethod 
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Page 1: MAINMENU: :#Button40: :pushButton* 


; COMMENT: INSTRUCTIONS HOW TO ARCHIVE DATA 
method pushButton(var eventInfo Event) 


;declares contextHelp string to be used in 
z;info box 


var 
contextHelp String 
endVar 


;opens up an info box and displays 
iquoted info in box and names the 
jbox LEVRAS ARCHIVE 


beep () 

contextHelp = "As per NPS Security 
Regulation, retain Ticket hardcopy 
report for archives. Refer to 
LEVRAS User's Manual 

for archive instructions." 
contexthelp.view("LEVRAS ARCHIVE") 


endmethod 
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Page 1: CUSTOMER: :#Button39: :pushButton* 


; COMMENT: ADDS NEW RECORD TO CUSTOMER TABLE 
method pushButton(var eventInfo Event) 
;declare Customer table 

var 

custTbl Table 

endVar 
jinserts a record into Customer.DB table 

beep () 

action (DataBeginEdit) 

action (DataInsertRecord) 

custTbl.attach( "Customer. DB") 


action (DataPostrecord) 


endmethod 


Page 1: CUSTOMER: : #Button41: :pushButton* 


;COMMENT: MODIFIES FIELD(S) IN A RECORD OF CUSTOMER TABLE 
method pushButton(var eventinfo Event) 
;declares the Customer table 

var 

custTbl Table 

endVar 
jedits a record in the Customer.DB table 
beep () 
action (DataBeginEdit) 
custTbl. attach ("Customer. DB") 
action (DataPostRecord) 


action (DataEndEdit) 


endmethod 
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Page 1: CUSTOMER: :#Button43: :pushButton* 


; COMMENT: DELETES A RECORD FM CUSTOMER INFORMATION 
i TABLE 


method pushButton(var eventInfo Event) 
;declare string to be used in a dialog box 


var 
response String 
endVar 


;dialog box ensures user truly desires to delete a record 


response = msgQuestion("Delete Record?", “Delete this selected record?") 
if (response = "Yes")then 
action (DataDeleteRecord) 
if (response = "no") then 
action (DataPostRecord) 
endif 
endif 
beep () 


endmethod 


Page 1: CUSTOMER: : #Button72: :puehButton* 


; COMMENT: CUSTOMER FORM CONTEXT HELP STRING 
method pushButton(var eventInfo Event) 


;declares the contextHelp String to create a 
zhelp box. | 


var 
contextHelp String 
endVar 


beep () 

contextHelp = "Refer to LEVRAS User's Manual 
for help and/or push F1.";info to be displayed - 
j;in the LEVRAS HELP Box. 
contexthelp.view("LEVRAS HELP"); title of the 
;HELP box. 


endmethod 
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Page 1: CUSTOMER: : #Button76 : :pushButton* 


; COMMENT: RETURNS CUSTOMER FORM TO MAIN FORM 
method pushButton(var eventInfo Event) 
;declares the Main Menu form 


var 


mainForm Form; declaring MainMenu form. 
endVar 


;Oopens the Main Menu form and then closes the 
;Customer Information form 


mainForm.open("mainmenu"); opens Main Menu. 
mainForm.show(); shows Main Menu on CRT. 
close(); closes the Customer Information screen. 


endmethod 


Page 1: 8:\CUSTOMER: : #Button74: :pushButton* 


; COMMENT: ADVANCES CUSTOMER INFORMATION FORM TO 
: DRIVER LISENCE INFORMATION FORM 


method pushButton(var eventinfo Event) 
;declares driver lisence form and its table 


var 
advrilForm Form; 
driviIbl Table 
endVar 


;fowards Customer Information screen to Driver License 
;ecreen by opening Driver License table and form, and 
;then closes the Customer Information Screen. 


drivibl.attach("Driverli.DB") 


if not lock(drivTbl, "Write", "Driverli.DB", "Write") then 
endif; for multiuser use...only one user can use table 


dvrlForm. open ("Dvrlisen") ; 
avrlForm. show () 

close () 

endmethod 











Page 1: CUSTOMER: :TheList: :arrive* 


;COMMENT: RANK INFORMATION TO BE SELECTED IN 


;THE RANK FIELD OF THE CUSTOMER INFORMATION SCREEN 


method arrive(var eventInfo MoveEvent) 


jlists rank selections to be selected in a scroll 
jbox (in sequential order) 


TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
Thelist.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheList.list. 
TheLiat.list. 
TheList.liet. 


endmethod 


selection = 1 
value = "E1" 
selection = 2 
value = "E2" 
selection = 3 
value = "E53" 
selection = 4 
value = "B4" 
selection = 5 
value = "B85" 
selection = 6 
value = "6" 
selection = 7 
value = "E7" 
selection = 8 
value = "Bs" 
selection = 9 
value = "E9" 
selection = 10 
value = "Wi" 
selection = 11 
value = "Ww2" 
selection = 12 
value = "w3" 
selection = 13 
value = "wa" 
selection = 14 
value = "ws" 
selection = 15 
value = "O01" 
selection = 16 
value = "02" 
selection = 17 
value = "03" 
selection = 18 
value = "04" 
selection = 19 
value = "oO5" 
selection = 20 
value = "O06" 
eelection = 21 
value = "0O7" 
selection = 22 
value = "os" 
selection = 23 
value = "09" 
selection = 24 
value = "010" 
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Page 1: B:\CUSTOMER: :TheList: :arrive* 


;COMMENT: EMPLOYEE TYPE INFORMATION TO BE 
; SELECTED IN THE EMPLOYEE TYPE FIELD ON THE 
; CUSTOMER INFORMATION SCREEN 


method arrive(var eventInfo MoveEvent) 


jliste choices for selection by a LEVRAS 
juser (list in sequential order as shown 
; below) 


TheList.list.selection = 1 
TheList.list.value = "co" 
TheList.list.selection = 2 
TheList.list.value = "AcpU" 
TheList.list.selection = 3 
TheList.list.value = "MILRES" 
TheList.list.selection = 4 
TheList.list.value = "RETMII" 
TheList.list.selection = 5 
TheList.list.value = "CIVvGov" 
TheList.list.selection = 6 
TheList.list.value = "COMMERCIAL" 
TheList.list.selection = 7 
TheList.list.value = "MILDEP" 
TheList.list.selection = 8 
TheList.list.value = "DISVET* 


endmethod 


Page 1: CUSTOMER: :TheList: :arrive* 


; COMMENT : SEX INFORMATION TO BE SELECTED 

;IN THE SEX FIELD ON THE CUSTOMER INFORMATION 
; SCREEN | 

method arrive(var eventInfo MoveEvent) 

;liste two choices: either male or female 
TheList.list.selection = il 

TheList.list.value = "MALE" 
TheList.list.selection = 2 


TheList.list.value = "FEMALE" 


endmethod 
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Page 1: CUSTOMER: :TheList::arrive* 


; COMMENT: GRADE INFORMATION TO BE SELECTED 
;7IN THE GRADE FIELD OF THE CUSTOMER INFORMATION 
; SCREEN 


method arrive(var eventiInfo MoveEvent) 


jlists grade selections to be selected in a scroll 
jbox (and in sequential order, as shown below) 


TheList.list.selection = 1 
TheList.list.value = "ASi" 
TheList.list.selection = 2 
TheList.list.value = "AS2°* 
TheLiest.list.selection = 3 
TheList.list.value = "AS3" 
TheList.list.selection = 4 
TheList.list.value = "Ag4* 
TheList.list.selection = 5 
TheList.liet.value = "Ags" 
TheList.liet.selection = 6 
TheList.list.value = "As6" 
TheList.list.selection = 7 
TheList.list.value = "AS7" 
TheList.list.selection = 8 
TheList.list.value = "GM13" 
TheList.list.selection = 9 
TheList.list.value = "qym4" 
TheList.list.selection = 10 
TheList.list.value = "GM15" 
TheList.list.selection = 11 
TheList.list.value = "GS1" 
TheList.list.selection = 12 
TheList.list.value = "Gs2" 
TheList.list.selection = 13 
' TheList.list.value = "Gs3" 
TheList.list.selection = 14 
TheList.list.value = "GS4" 
TheList.list.selection = 15 
TheList.list.value = "Gs5" 
TheList.list.selection = 16 
TheList.list.value = "Gs6" 
TheList.list.selection = 17 
TheList.list.value = "Gs7" 
TheList.list.selection = 18 
TheList.list.value = "Gss" 
TheList.list.selection = 19 
TheList.list.value = "Gs9" 
TheList.list.selection = 20 
TheLiet.list.value = "GSi0" 
TheList.list.selection = 21 
TheList.list.value = "GS11" 
TheList.list.selection = 22 
TheList.list.value = "GSi2" 
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Page 2: CUSTOMER: :TheList: :arrive* 


TheLiet.list.selection = 23 
TheList.list.value = "GS13" 
TheList.list.selection = 24 
TheList.list.value = "GS14" 
TheList.list.selection = 25 
TheList.list.value = "GS15" 
TheList.list.selection = 26 
TheList.list.value = "@Ssi6" 
TheList.list.selection = 27 
TheList.liet.value = "GS17" 
TheList.list.selection = 28 
TheList.liet.value = "GSs18" 
TheList.list.selection = 29 
TheList.list.value = "NA1" 

TheList.list.gselection = 30 
TheList.list.value = "NA2" 

TheList.list.selection = 31 
TheList.list.value = "NA3" 

TheList.liet.selection = 32 
TheList.list.value = "NA4" 

TheList.list.selection = 33 
TheList.list.value = "NA5" 

TheList.list.selection = 34 
TheList.list.value = "NA6" 

TheList.list.selection = 35 
TheList.list.value = "NA7" 

TheList.list.selection = 36 
TheLiet.list.value = "NA8" 

TheList.list.selection = 37 
TheList.list.value = "NA9" 

TheList.liet.selection = 38 
TheList.list.value = "NAO" 
TheList.list.selection = 39 
TheList.list.value = "NAi1" 
TheList.list.selection = 40 
TheList.list.value = "NA12" 
TheList.list.selection = 41 
TheList.list.value = "NA13°" 
TheList.list.selection = 42 
TheLiet.list.value = "NA14" 
TheList.list.selection = 43 
TheList.list.value = "NA15" 
TheList.list.gselection = 44 
TheList.list.value = "NL1" 

TheList.list.selection = 45 
TheList.list.value = "NL2" 

TheLiet.list.selection = 46 
TheList.list.value = "NL3"*" 

TheList.list.selection = 47 
TheLiet.list.value = "NL4" 

TheList.list.selection = 48 
TheList.list.value = "NL5" 

TheList.list.selection = 49 
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Page 3: CUSTOMER: :TheLiest: :arrive* 


TheList.list.value = "NLé" 
TheList.list.selection = 50 
TheList.list.value = "NL7" 
TheList.list.selection = $1 
TheList.list.value = "NL8" 
TheList.list.selection = 52 
TheList.list.value = "NL9" 
TheList.list.selection = 53 
TheList.list.value = "NL10" 
TheList.list.selection = 54 
TheList.list.value = "NL11" 
TheList.list.selection = 55 
TheList.list.value =< "NL12"* 
TheList.list.selection = 56 
TheList.list.value = "NL13" 
TheList.list.selection = 57 
TheList.list.value = "NL14" 
TheList.list.selection = 58 
TheList.list.value = "NL15" 
TheList.list.selection = 59 
TheList.list.value = "Psi" 
TheList.list.selection = 60 
TheList.list.value = "Ps2" 
TheList.list.selection = 61 
TheList.list.value = "PS3" 
TheList.list.selection = 62 
TheList.list.value = "Ps4" 
TheList.list.selection = 63 
TheList.list.value = "Ps5" 
TheList.list.selection = 64 
TheList.list.value = "Ppseé" 
TheList.list.selection = 65 
TheList.list.value = "PS7" 
TheList.list.selection = 66 
’ TheList.list.value = "WD1" 
TheList.list.selection = 67 
TheList.list.value = "WD2" 
TheList.list.selection = 68 
TheList.list.value = "WD3" 
TheList.list.selection = 69 
TheList.list.value = "wD4" 
TheList.list.selection = 70 
TheList.list.value = "WD5" 
TheList.list.selection = 71 
TheList.list.value = "WD6" 
TheList.list.selection = 72 
TheList.list.value = "wD7" 
TheList.list.selection = 73 
TheList.list.value = "WD8" 
TheList.list.selection = 74 
TheList.list.value = "WD9" 
TheList.list.selection = 75 
TheLiet.list.value = "wWD10" 
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Page 4: CUSTOMER: :TheList: :arrive* 


TheList.list.selection = 76 
TheList.list.value = "WDii" 
TheList.list.selection = 77 
TheList.list.value = "WwD12" 
TheList.list.selection = 78 
TheList.list.value = "WD13" 
TheList.list.selection = 79 
TheLiet.list.value = "WD14" 
TheList.list.selection = 80 
TheList.list.value = "WD15" 
TheList.list.selection = 81 
TheList.list.value = "“wb16é" 
TheLiet.list.selection = 82 
TheList.list.value = "WD17" 
TheList.list.selection = 83 
TheList.list.value = "wp18" 
TheList.list.selection = 84 
TheList.list.value = "WD19" 
TheList.list.selection = 85 
TheList.list.value = "WGi" 
TheList.list.selection = 86 
TheList.list.value = "WG2" 
TheList.list.selection = 87 
TheList.list.value = "WG3" 
TheList.list.selection = 88 
TheLiet.list.value = "WwG4" 
TheList.list.selection = 8&9 
TheList.liet.value = "WG5" 
TheList.list.selection = 90 
TheList.liest.value = "WwG6" 
TheList.list.selection = 91 
TheList.list.value = "WG7" 
TheList.list.selection = 92 
TheList.list.value = "WG8*" 
TheLiest.list.selection = 93 
TheLiet.list.value = "WG9" 
TheList.list.selection = 94 
TheList.list.value = "WG10" 
TheList.list.selection = 95 
TheList.liet.value = *wWGi1" 
TheList.list.selection = 96 
TheList.list.value = "WG12" 
TheLiet.list.selection = 97 
TheList.list.value = "WG1i3" 
TheLiet.list.selection = 98 
TheList.list.value = "WG14" 
TheList.list.selection = 99 
TheList.list.value = "WG15" 
TheList.list.selection = 100 
TheList.list.value = "WL1" 
TheList.list.selection = 101 
TheList.list.value = "WL2" 
TheList.list.selection = 102 
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Page 5: CUSTOMER: :TheList: :arrive* 


TheList.list.value = "WL3" 
TheList.list.selection = 103 
TheLiet.list.value = "WL4" 
TheList.list.selection = 104 
TheList.list.value = "WL5" 
TheList.list.selection = 105 
TheList.list.value = "WL6é" 
TheList.list.selection = 106 
TheList.list.value = "WI7" 
TheList.list.selection = 107 
TheList.list.value = "WL8" 
TheList.list.selection = 108 
TheList.list.value = "WL9" 
TheList.list.aselection = 109 
TheList.list.value = "WL10" 
TheList.list.selection = 110 
TheList.list.value = "WL1i" 
TheList.list.selection = 111 
TheList.list.value = "WL12" 
TheList.list.selection = 112 
TheList.list.value = "WL13" 
TheList.list.selection = 113 
TheList.list.value = "WL14" 
TheList.list.selection = 114 
TheList.list.value = "WL15" 
TheList.list.selection = 115 
TheList.liet.value = "WP1" 
TheList.list.selection = 116 
TheList.list.value = "WP2" 
TheList.list.selection = 117 
TheList.list.value = "WP3" 

- TheList.list.selection = 118 
TheList.list.value = "WP4" 

| Thebiet.liest.selection = 119 
TheList.list.value = "WP5" 
TheList.list.selection = 120 
TheList.list.value = "WP6" 
TheList.list.selection = 121 
TheList.list.value =< "WP7" 
TheLiet.list.selection = 122 
TheList.list.value = "WP8" 
TheLiset.list.selection = 123 
TheList.list.value = "WPS" 
TheList.list.selection = 124 
TheList.list.value = "WP10" 
TheList.list.selection = 125 
TheList.list.value = "WP11" 
TheList.list.selection = 126 
TheList.list.value = "WP12" 
TheList.list.selection = 127 
TheList.list.value = "WP13" 
TheList.list.selection = 128 
TheList.list.value = "WP14" 
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Page 6: CUSTOMER: :TheList: :arrive* 


TheList.liet.selection = 129 
TheList.list.value = "WP15" 
TheList.list.selection = 130 
TheList.list.value = "WP16" 
TheList.list.selection = 131 
TheList.list.value = "WP17" 
TheList.list.selection = 132 
TheList.list.value = "WP18" 
TheList.list.selection = 133 
TheList.list.value = "WP19" 
TheList.liet.selection = 134 
TheList.list.value = "WP20" 
TheList.list.selection = 135 
TheList.list.value = "WP21" 
TheList.list.selection = 136 
TheLiest.list.value = "WP22" 
TheList.list.selection = 137 
TheList.list.value = "WP23" 
TheList.list.selection = 138 
TheList.list.value = "WP24" 
TheList.list.selection = 139 
TheList.list.value = "WP25" 
TheList.list.selection = 140 
TheList.list.value = "WP26" 
TheList.list.selection = i141 
TheList.list.value = "WP27" 
TheList.list.selection = 142 
TheList.list.value = "WP28" 
TheList.list.selection = 143 
TheList.list.value = "WP29" 
TheLiet.list.selection = 144 
TheLiet.list.value = "WP30" 
TheList.list.selection = 145 
TheLiet.list.value = "WP31" 
TheList.list.selection = 146 
TheList.list.value = "WP32" 
TheList.list.selection = 147 
TheLiet.list.value = "WP33" 
TheList.list.selection = 148 
TheList.list.value = "WP34" 
TheList.list.selection =< 149 
TheList.list.value = "WP35" 
TheList.list.selection = 150 
TheList.list.value = "WP36" 
TheList.list.selection = 151 
TheList.list.value = “WP37" 
TheList.list.selection = 152 
TheList.list.value = "WP38" 
TheList.list.selection = 153 
TheList.list.value = "WP39" 
TheList.list.selection = 154 
TheList.list.value = "WP40" 
TheList.list.selection = 155 
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Page 7: CUSTOMER: :TheList: :arrive* 


TheLiest.list.value = "WP41" 
TheList.list.selection = 156 
TheList.list.value = "WP42" 
TheList.list.selection = 157 
TheList.list.value = "WP43" 
TheList.list.selection = 158 
TheLiest.list.value = "WP44" 
TheList.list.selection = 159 
TheList.liet.value = "wp45" 
TheList.list.selection = 160 
TheList.list.value = "WP46" 
TheList.list.selection = 161 
TheList..list.value = "WP47" 
TheList.list.selection = 162 
TheList.list.value = "WP48" 
TheList.list.selection = 163 
TheList.list.value = "WP49" 
TheList.list.selection = 164 
TheLiet.liet.value = "WP50" 
TheList.list.selection = 165 
TheList.list.value = "WP51" 
TheLiest.list.selection = 166 
TheList.list.value = "WP52" 
TheList.list.selection = 167 
TheList.list.value = "WP53" 
TheList.list.selection = 168 
TheList.list.value = "WP54" 
TheLiet.list.selection = 169 
TheList.list.value = "WP55" 
TheLiet.list.selection = 170 
TheList.list.value = "WP56" 
TheList.list.selection = 171 
TheList.list.value = "WP57" 
TheLiet.list.selection = 172 
TheList.list.value = "WP58" 
TheList.list.selection = 173 
TheList.list.value = "WP59" 
TheList.list.selection = 174 
TheList.list.value = "WPé0" 
TheList.list.selection = 175 
TheList.list.value = "WP61" 
TheList.list.selection = 176 
TheList.list.value = "WP62" 
TheList.list.selection = 177 
TheList.list.value = "WP6é3" 
TheList.list.selection = 178 
TheList.list.value = "WP6é4" 
TheList.list.selection = 179 
TheList.list.value = "WPé5" 
TheList.list.selection = 180 
TheList.list.value = "WP66" 
TheList.list.selection = 181 
TheList.list.value = "WP67" 
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Page 8: CUSTOMER: :TheList: :arrive* 


TheLiest.list.selection = 182 
TheList.list.value = "WP6é8" 
TheList.list.selection = 183 
TheList.list.value = "WP69" 
TheList.list.selection = 184 
TheList.list.value = "WP70" 
TheLiet.list.selection = 185 
TheLiet.liest.value = "WP71" 
TheList.list.selection = 186 
TheList.list.value = "“WP72" 
TheLiet.list.selection = 187 
TheList.list.value = "WP73" 
TheList.list.selection = 188 
TheList.list.value = "WP74" 
TheList.list.selection = 189 
TheList.liet.value = "WP75" 
TheList.list.selection = 190 
TheList.list.value = "WP76" 
TheList.liet.selection = 191 
TheList.liet.value = "WP77" 
TheList.list.selection = 192 
TheList.list.value = "WP78" 
TheList.list.selection = 193 
TheList.list.value = "WS1" 
TheList.list.eelection = 194 
TheList.list.value = "WS2" 
TheList.list.selection = 195 
TheList.list.value = "Ws3" 
TheList.list.selection = 196 
TheList.list.value = "WS4" 
TheList.liet.selection = 197 
TheList.list.value = "ws5s" 
TheList.list.selection = 198 
TheList.list.value = "wS6é" 
TheList.list.selection = 199 
TheList.list.value = "WS7" 
TheList.list.selection = 200 
TheList.list.value = "wss" 
TheList.list.selection = 201 
TheList.list.value = "Wws9" 
TheList.list.selection = 202 
TheList.list.value = "WS10" 
TheList.list.selection = 203 
TheList.list.value = "WS11" 
TheList.list.selection = 204 
TheList.list.value = "WS12" 
TheList.list.selection = 205 
TheList.list.value = "wWS13" 
TheList.list.selection = 206 
TheList.list.value = "WS14" 
TheList.list.selection = 207 
TheLiet.list.value = "W515" 
TheList.list.selection = 208 


142 








Page 9: CUSTOMER: :TheList: :arrive* 


TheList.list.value = "wS16" 
TheList.list.selection = 209 
TheList.list.value = "WS17" 
TheList.list.selection = 210 
TheList.list.value = "ws1s" 
TheList.list.selection = 211 
TheList.list.value = "ws19" 
TheList.list.selection = 212 
TheList.liet.value = "WT1" 
TheList.list.selection = 213 
TheList.list.value = "WT2" 
TheList.list.selection = 214 
TheList.list.value = "WT3" 
TheList.list.selection = 215 
TheList.list.value = "WT4" 
TheList.list.selection = 216 
TheList.list.value = "WT5" 
TheList.list.selection = 217 
TheLiet.list.value = "WT6" 
TheList.list.selection = 218 
TheList.list.value = "WI'7" 
TheList.list.selection = 219 
TheLiest.list.value = "WwTrs" 
TheLiet.list.selection = 220 
TheList.list.value = "wTs" 
TheList.list.selection = 221 
TheList.list.value = "WT11" 
TheList.list.selection = 222 
TheList.list.value = "WT12" 
TheList.list.selection = 223 
TheList.list.value = "WT13" 
TheList.list.selection = 224 
TheList.list.value = "WT14" 
TheList.list.selection = 225 

| TheList.list.value = "WT15" 
TheList.list.selection = 226 
TheList.list.value = "WT16" 
TheList.list.selection = 227 
TheList.list.value = "WT17" 

| TheList.list.selection = 228 
TheList.list.value = "WT18" 
TheList.list.selection = 229 
TheList.list.value = "YyVv" 
TheList.list.selection = 230 
TheList.list.value = "Yw" 


endmethod 
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Page 1: CUSTOMER: :TheList: :arrive* 


;COMMENT: LISTS OF STATE CODES IN THE 

;HOME STATE FIELD ON THE CUSTOMER INFORMATION 
;SCREEN (ALSO INCLUDES SOME COUNTRY CODES) 
;SEE LEVRAS USER MANUAL FOR CODE BREAKOUTS 


method arrive(var eventInfo MoveEvent) 


ilists choices to be selected by user 
; (listed in sequential order) 


TheList.list.selection = 1 
TheList.list.value = "AL" 
TheList.list.selection = 2 
TheList.list.value = "AK* 
TheList.list.selection = 3 
TheList.list.value = "AR" 
TheLiet.list.selection = 4 
TheList.list.value = "AS" 
TheList.list.selection = 5 
TheList.list.value = "AZ" 
TheList.list.selection = 6 
TheList.list.value = "BG" 
TheList.list.selection = 7 
TheLiet.liet.value = "CA" 
TheList.list.selection = 8 
TheList.list.value = "CN" 
TheList.list.selection = 9 
TheList.list.value = "CO" 
TheList.list.selection = 10 
TheList.list.value = "cT* 
TheList.list.selection = 11 
TheList.list.value = "Cz" 
TheList.list.selection = 12 
TheList.liet.value = "DC" 
TheList.list.selection = 13 
TheList.liet.value = "DE" 
TheList.list.selection = 14 
TheList.list.value = "DM" 
TheList.list.selection = 15 
TheList.list.value = "FL" 
TheList.list.selection = 16 
TheLiet.liest.value = "FR" 
TheList.list.selection = 17 
TheList.list.value = "GA" 
TheList.liet.selection = 18 
TheList.liet.value = "GM" 
TheList.list.selection = 19 
TheList.list.value = "GR" 
TheList.list.selection = 20 
TheList.list.value = "GU" 
TheList.list.selection = 21 
TheList.liet.value = "HI" 
TheList.list.selection = 22 
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TheList.list.value = "IA" 
TheList.list.selection = 23 
TheList.list.value = "Ic" 
TheList.list.selection = 24 
TheList.liet.value = "ID" 
TheList.list.selection = 25 
TheList.list.value = "IL" 
TheList.list.selection = 26 
TheList.list.value = "IN" 
TheList.list.selection = 27 
TheList.list.value = "IT" 
TheList.list.selection = 28 
TheList.list.value = "Ky" 
TheList.list.selection = 29 
TheList.list.value = "Ks" 
TheList.list.selection = 30 
TheLiet.list.value = "LA" 
TheList.list.selection = 31 
TheList.list.value = "Lx" 
TheList.list.selection = 32 
TheList.list.value = "MA" 
TheList.list.selection = 33 
TheList.list.value = "MD" 
TheList.list.selection = 34 
TheList.list.value = "ME" 
TheLiest.list.selection = 35 
TheList.list.value = "MI" 
TheList.list.selection = 36 
TheLiet.list.value = "MN" 
TheList.list.selection = 37 
TheList.list.value = "MO" 
TheList.list.selection = 38 
TheList.list.value = "MS" 
TheList.list.selection = 39 
TheList.list.value = "MT" 
TheLiest.list.selection = 40 
TheList.list.value = "NC" 
TheList.list.selection = 41 
TheList.list.value = "ND" 
TheList.list.selection = 42 
TheList.list.value = "NE" 
TheList.liet.selection = 43 
TheList.list.value = "NH* 
TheList.list.selection = 44 
TheList.list.value = "NJ" 
TheList.list.selection = 45 
TheList.list.value = "NL" 
TheList.list.selection = 46 
TheList.list.value = "Nm" 
TheList.list.selection = 47 
TheList.list.value = "Nv" 
TheList.liet.selection = 48 
TheList.list.value = "Nw*" 
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TheList.liet.selection = 49 
TheList.list.value = "Ny" 
TheList.list.selection = 50 
TheList.list.value = "OH" 
TheList.list.selection = 51 
TheList.list.value = "OK" 
TheList.list.selection = 52 
TheList.list.value = "OR" 
TheList.list.selection = 53 
TheList.list.value = "PA" 
TheList.list.selection = 54 
TheList.list.value = "PR" 
TheList.list.selection = 55 
TheList.lieat.value = "PT" 
TheList.list.selection = 56 
TheList.list.value = "RI" 
TheList.list.selection = 57 
TheList.list.value = "Sc" 
TheList.liet.geelection = 58 
TheList.list.value = "SD" 
TheList.list.selection = 59 
TheList.list.value = "TN" 
TheList.list.selection = 60 
TheList.list.value = "TK" 
TheList.list.selection = 61 
TheLiest.list.value = "TT" 
TheLiet.list.selection = 62 
TheList.liet.value = "TX" 
TheList.list.selection = 63 
TheList.list.value = "VI" 
TheList.list.selection = 64 
TheList.list.value = "UK" 
TheList.list.selection = 65 
TheList.list.value = "UT" 
TheList.list.selection = 66 
TheList.list.value = "VA" 
TheList.list.selection = 67 
TheList.list.value = "VI" 
TheList.list.selection = 68 
TheList.list.value = "WA" 
TheList.list.selection = 69 
TheList.list.value = "WI" 
TheList.list.selection = 70 
TheList.list.value = "wv" 
TheList.list.selection = 71 
TheList.list.value = "Wy" 
TheList.list.selection = 72 
TheList.list.value = "XX" 


endmethod 
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; COMMENT: LISTS LAST TWO DIGITS OF YEAR OF VEHICLE 

i STARTING WITH 50 TO 01 (1950 TO 2001) ON 

? THE VEHICULAR INFORMATION FORM IN THE VEHICLE 
; YEBAR FIELD 


method arrive(var eventInfo MoveEvent) 


;listes last two digits of year in order shown below. 
;the information is displayed in a drop down box with 
sa vertical scroll box. 


TheLiet.list.selection = 1 
TheList.list.value = "50" 
TheList.list.selection = 2 
TheList.list.value = "51" 
TheList.list.selection = 3 
TheLiet.liet.value = "52" 
TheList.list.selection = 4 
TheList.list.value = "53" 
TheList.list.selection = 5 
TheList.list.value = "54" 
TheLiet.list.selection = 6 
TheList.list.value = "55" 
TheList.list.selection = 7 
TheList.list.value = "56" 
TheList.list.selection = 8 
TheList.list.value = "57" 
TheList.list.selection = 9 
TheList.list.value = "58" 
TheList.list.selection = 10 
TheList.list.value = "59" 
TheList.list.selection = 11 
TheList.list.value = "60" 
TheLiet.list.selection = 12 
TheList.list.value = "61" 
TheList.list.selection = 13 
i'TheList.list.value = "62" 
TheList.list.selection = 14 
TheList.list.value = "63" 
TheList.list.selection = 15 
TheList.list.value = "64" 
TheList.list.selection = 16 
| TheList.list.value = "65" 
TheList.list.selection = 17 
TheList.list.value = "66" 
TheList.list.selection = i18 
TheList.list.value = "67" 
TheList.list.selection = 19 
TheList.list.value = "68" 
TheList.list.selection = 20 
TheList.list.value = "69" 
TheList.list.selection = 21 
TheList.list.value = "70" 
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TheLiet.list.selection = 22 
TheList.list.value = "71" 
TheList.list.selection = 23 
TheLiet.list.value = "72" 
TheList.list.selection = 24 
TheList.list.value = "73" 
TheList.list.selection = 25 
TheList.liet.value = "74" 
TheList.list.selection = 26 
TheList.list.value = "75°" 
TheList.list.selection = 27 
TheList.list.value = "76" 
TheList.list.selection = 28 
TheList.list.value = "77" 
TheList.list.selection = 29 
TheList.list.value = "78" 
TheList.list.selaction = 30 
TheList.list.value = "79" 
TheList.list.selection = 31 
TheList.list.value = "80" 
TheList.list.selection = 32 
TheList.list.value = "81" 
TheList.list.selection = 33 
TheLiet.list.value = "82" 
TheList.list.selection = 34 
TheList.list.value = "83" 
TheList.list.selection = 35 
TheList.list.vaiue = "84" 
TheList.list.selection = 36 
TheList.liet.value = "85" 
TheList.list.selection = 37 
TheList.list.value = "86" 
TheList.list.eelection = 38 
TheLiet.list.value = "87" 
TheList.list.selection = 39 
TheList.list.value = "88" 
TheList.list.selection = 40 
TheLisat.list.value = "89" 
TheList.list.selection = 41 
TheList.list.value = "90" 
TheList.list.selection = 42 
TheList.list.value = "91" 
TheList.list.selection = 43 
TheList.list.value = "92" 
TheList.list.selection = 44 
TheList.list.value = "93" 
TheList.list.selection = 45 
TheLiet.list.value = "94" 
TheList.liest.selection = 46 
TheList.list.value = "95" 
TheList.list.selection = 47 
TheList.list.value = "96" 
TheList.list.selection = 48 
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TheList.list.value = "97" 
TheList.list.selection = 49 
TheList.list.value = "98" 
TheList.list.selection = 50 
TheList.list.value = "99" 
TheList.list.selection = 51 
TheList.list.value = "00" 
TheList.list.selection = 52 
TheList.list.value = "01" 


endmethod 
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;COMMENT: LISTS VEHICLE MAKE ON THE VEHICULAR INFORMATION 
i SCREEN 


method arrive(var eventInfo MoveEvent) 


;lists vehicle makes in the order shown below in a 
;adrop down window with a scroll box 


TheList.list.selection = 1 
TheList.list.value = "ACURA" 
TheList.list.selection = 2 
TheList.list.value = "ALPHA" 
TheList.list.selection = 3 
TheList.list.value = "AMC" 
TheList.list.selection = 4 
TheList.list.value = "AUDI" 
TheList.list.selection = 5 
TheList.list.value = "BENZ" 
TheList.list.selection = 6 
TheList.list.value = "BMW" 
TheList.list.selection = 7 
TheList.list.value = "BUICK" 
TheList.list.selection = 8 
TheList.list.value = "CADI" 
TheList.list.selection = 9 
TheList.list.value = "CHEV" 
TheList.list.selection = 10 
TheList.list.value = "CHRY" 
TheList.list.selection = 11 
TheList.list.value = "DATSU" 
TheList.list.selection = 12 
TheList.list.value = "DODGE" 
TheList.list.selection = 13 
TheList.list.value = "EAGLE" 
TheList.list.selection = 14 
TheList.list.value = "FIAT" 
TheList.list.selection = 15 
TheList.list.value <« "FORD" 
TheList.list.selection = 16 
TheList.list.value = "GEO" 
TheList.list.selection = 17 
TheList.list.value = "GMC" 
TheList.list.selection = 18 
TheList.list.value = "HONDA" 
TheList.list.selection = 19 
TheList.list.value = "HRLY" 
TheList.list.selection = 20 
TheList.list.value = "HYUN" 
TheList.list.selection = 21 
TheList.list.value = "INFI" 
TheList.liet.selection = 22 
TheList.list.value = "Isuzv" 
TheList.list.selection = 23 
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TheList.list.value = "JAGU" 
TheLiet.list.selection = 24 
TheList.list.value = "JEEP" 
TheList.list.selection = 25 
TheList.list.value = "KAWA" 
TheList.list.selection = 26 
TheList.list.value = "LEXUS" 
TheList.list.selection = 27 
TheList.list.value = "LINC" 
TheList.list.selection = 28 
TheLiet.list.value = "MAZDA" 
TheList.list.eelection = 29 
. TheList.list.value =< "MERC" 
TheList.list.selection = 30 
TheList.list.value = "MG" 
TheList.list.selection = 31 
TheList.list.value = "MITSU" 
TheList.list.selection = 32 
TheList.list.value = "NISS" 
TheList.list.selection = 33 
TheList.list.value = "OLDS" 
TheList.list.selection = 34 
TheList.list.value = "PEUGO" 
TheList.list.selection = 35 
TheList.list.value = "PLYM" 
TheList.list.selection = 36 
Thelist.list.value = "PONTI" 
ThehList.list.selection = 37 
TheList.list.value = "PORS" 
TheList.list.selection = 38 
TheList.list.value = "RENAU" 
TheList.list.selection = 39 
TheList.list.value = "SAAB" 
TheList.list.selection = 40 
TheList.list.value = "SATUR" 
TheList.list.selection = 41 
TheList.list.value = "SUBA" 
TheLiet.list.eelection = 42 
TheList.list.value = "SUZI" 
TheLiet.list.selection = 43 
TheList.list.value = "TOYO" 
TheList.list.selection = 44 
TheList.list.value = "VOLVO" 
TheList.list.selection = 45 
TheList.list.value = "Vw" 
TheList.list.selection = 46 
TheList.list.value = "YAMA" 
TheList.list.selection = 47 
TheList.list.value = "YUGO" 
TheList.list.selection = 48 
TheList.list.value = "OTHER" 


endmethod 
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;COMMENT: LISTS VEHICLE COLOR ON THE VEHICULAR INFORMATION 
i SCREEN 


method arrive(var eventInfo MoveEvent) 


z:lists vehicle colors in the vehicle color field (in the 
;order shown below) 


TheList.list.selection = i 
TheList.list.value = "BEIGE" 
TheList.list.selection = 2 
TheList.list.value = "BLACK" 
TheList.list.selection = 3 
TheList.list.vailue = "BLUE" 
TheList.list.selection = 4 
TheList.list.value = "BRONZE" 
TheList.list.selection = 5 
TheList.list.value = "BROWN" 
TheList.list.selection = 6 
TheList.list.value = "GOLD" 
TheList.list.selection = 7 
TheList.list.value = "GRAY" 
TheList.list.selection = 8 
TheList.list.value = "GREEN" 
TheList.list.selection = 9 
TheList.list.value = "MAROON" 
TheList.list.selection = 10 
TheList.list.value = "MUSTARD" 
TheList.list.selection = 11 
TheList.list.value = "ORANGE" 
TheList.list.selection = 12 
TheList.list.value = "PEACH" 
TheList.list.selection = 13 
TheList.list.value = "PINK" 
TheList.list.selection = 14 
TheList.list.value = "PURPLE" 
TheList.list.selection = 15 
TheList.list.value = "RED" 
TheList.list.selection = 16 
TheList.liet.value = "RUST" 
TheList.list.selection = 17 
TheList.list.value = "SILVER" 
TheList.list.selection = 18 
TheLiest.list.value = "TBAL" 
TheList.list.selection = 19 
TheList.list.value = "WHITE" 
TheList.list.selection = 20 
TheList.list.value = "YELLOW" 
TheList.list.selection = 21 
TheList.list.value = "OTHER" 


endmethod 
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; COMMENT: GOES BACK TO CUSTOMER INFORMATION FORM 
; FROM DRIVER LICENSE FORM 


method pushButton(var eventinfo Event) 
;declares customer table and form 


var 
custTbl Table 
custForm Form 
endVar 


sreverte back to customer form fm driver license 
;form by opening Customer table and form, and 
;then closes the Driver License Information Screen 


custTbl.attach("Customer.DB") 

if not lock(custTbl, "FULL", "customer.db", "FULL") then 
endIf£ 

custForm. open ("Customer") 

custForm. show () 

close () 


endmethod 
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;COMMENT: RETURNS DRIVER LICENSE FORM TO MAIN FORM 
method pushButton(var eventInfo Event) 
;declares Main Menu Form 
var 
mainForm Form; declaring MainMenu form. 
endVar 
:returns to the Main Menu form from the Driver 
sLicense form and then closes the Driver 
;License Information Screen 
mainForm.open("mainmenu"); opens Main Menu. 
mainForm. show () 


close () 


endmethod 
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;COMMENT: LISTS VEHICLE DECAL EXPIRATION YEAR IN THE 
; DECAL EXPIRATION YRAR FIELD ON THE DECAL 
; INFORMATION SCREEN 


method arrive(var eventInfo MoveEvent) 


jlists year 95 thru 01 (1995 - 2001) in the order 
;shown below. the list is displayed in a drop 
j;down scroll box. 


TheList.list.selection = 1 
TheList.list.value = "95" 
TheList.list.selection = 2 
TheList.list.value = "96" 
TheList.list.aelection = 3 
TheList.list.value = "97" 
TheList.list.selection = 4 
TheList.list.value = "98" 
TheList.list.selection = 5 
TheList.list.value = "99" 
TheList.list.selection = 6 
TheList.list.value = "00" 
TheList.list.selection = 7 
TheList.list.value = "01" 


endmethod 


Page 1: DECAL: :DecalColor: :arrive* 


;COMMENT: LISTS VEHICLE DECAL COLOR IN THE DECAL COLOR 
; FIELD ON THE DECAL INFORMATION SCREEN 


method arrive(var eventInfo MovekEvent) 


; lists decal colors in the decal color field (in the 
;order shown below) 


TheList.list.selection = 1 
TheList.list.value = "BLUE" 
TheList.list.selection = 2 
TheList.list.value = "GREEN" 
TheList.list.selection = 3 
TheList.list.value = "RED" 
TheList.list.selection = 4 
TheList.list.value = "WHITE" 
TheList.list.selection = 5 
TheList.list.value = "BLACK" 


endmethod 


155 








Page 1: DECAL: :DecalExpirationMonth: :arrive* 


;COMMENT: LISTS VEHICLE DECAL EXPIRATION MONTH IN THE DECAL 
; EXPIRATION FIELD 


method arrive(var eventInfo Movekvent) 


s;liste month from 01 thru 12 in the order shown below. 
jthe list is shown in a drop down scroll box. 


TheList.list.selection = 1 
TheList.list.value = "01" 
TheList.list.selection = 2 
TheList.list.value = "02" 
TheLiest.list.selection = 3 
TheList.list.value = "03" 
TheList.list.selection = 4 
TheList.list.value = "04" 
TheList.list.selection = 5 
TheList.list.value = "05" 
TheList.list.selection = 6 
TheList.list.value = "06" 
TheLiet.list.selection = 7 
TheLiet.list.value = "07" 
TheList.list.selection = 8 
TheList.list.value = "08" 
TheList.list.selection = 9 
TheList.list.value = "09" 
TheList.list.selection = 10 
TheList.list.value = "10° 
TheList.list.selection = 11 
TheList.list.value = "11" 
TheList.list.selection = 12 
TheList.list.value = "12" 


endmethod 
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COMMENT: LISTS TICKET VIOLATION CODES (01-99) IN THE 
VIOLATION CODE FIELD ON THE TICKET INFORMATION 
SCREEN 


=» Me | of 


method arrive(var eventInfo MoveEvent) 


;lists ticket violation code (01-99) in the order shown 
;below. the list is displayed in a drop down scroll box. 


TheList.list.selection = 1 
TheList.Llist.value = "01" 
TheList.list.selection = 2 
| TheLiet.list.value = "02° 
TheList.list.selection = 3 
TheList.list.value = "03" 
TheList.list.selection = 4 
TheList.list.value = "04" 
TheList.list.selection = 5 
TheList.list.value = "05" 
TheList.list.selection = 6 
TheList.list.value = "06" 
TheList.list.selection = 7 
TheList.list.value = "07" 
TheList.list.selection = 8 
TheList.list.value = "08" 
TheList.list.selection = 9 
TheList.list.value = "09" 
TheList.list.selection = 10 
TheList.list.value = "10" 
TheList.list.selection = 11 
YTheLiset.list.value = "11" 
TheList.list.selection = 12 
TheList.list.value = "12" 
TheList.list.selection = 13 
TheList.list.value = "13" 
TheList.list.selection = 14 
TheLiet.list.value = "14" 
TheList.list.selection = 15 
TheList.list.value = "15" 
iTheList.list.selection = 16 
TheList.list.value = "16" 
TheList.list.selection = 17 
TheList.list.value = "17" 
TheList.list.selection = 18 
TheList.list.value = "18" 
TheList.list.selection = 19 
eList.list.value = "19" 
eList.list.selection = 20 
heList.list.value = "20" 
heLiat.list.selection = 21 
heList.list.value = "21" 
TheList.list.selection = 22 
TheLiet.list.value = "22" 
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TheList.list.selection = 23 
TheList.list.value = "23" 
TheList.list.selection = 24 
TheList.list.value = "24" 
TheList.list.selection = 25 
TheLiet.list.value = "25" 
TheList.list.selection = 26 
TheList.list.value = "26" 
TheList.liet.selection = 27 
TheList.list.value = "27" 
TheList.list.selection = 28 
TheList.list.value = "28" 
TheList.list.selection = 29 
TheList.list.value = "29" 
TheList.list.selection = 30 
TheList.list.value = "30" 
TheList.list.selection = 31 
TheList.list.value = "31" 
TheLiest.list.selection = 32 
TheList.list.value = "32" 
TheList.list.selection = 33 
TheList.list.value = "33" 
TheList.list.selection = 34 
TheList.list.value = "34" 
TheList.list.selection = 35 
TheList.list.value = "35" 
TheList.list.selection = 36 
TheList.list.value = "36" 
TheList.list.selection = 37 
TheList.liet.value = "37" 
TheList.list.selection = 38 
TheList.liet.value = "38" 
TheList.list.selection = 39 
TheList.list.value = "39" 
TheList.list.selection = 40 
TheList.liet.value = "40" 
TheList.list.selection = 41 
TheList.list.value = "41" 
TheList.list.selection = 42 
TheList.list.value = "42" 
TheList.list.selection = 43 
TheList.list.value = "43" 
TheList.list.selection = 44 
TheList.list.value = "44" 
TheList.list.selection = 45 
TheLiet.list.value = "45" 
TheList.list.selection = 46 
TheList.list.value = "46" 
TheList.list.selection = 47 
TheLiet.liet.value = "47" 
TheList.list.selection = 48 
TheList.list.value = "48" 
TheList.list.selection = 49 
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TheLiet.list.value = "49" 
TheList.list.selection = 50 
TheList.list.value = "50" 
TheLiest.list.selection = 51 
TheList.list.value = "51" 
TheList.list.selection = 52 
TheList.list.value = "52" 
TheList.list.selection = 53 
TheList.list.value = "53" 
TheList.list.selection = 54 
TheList.list.value = "54" 
TheLiet.list.selection = 55 
TheList.list.value = "55" 
TheList.list.selection = 56 
TheList.list.value = "56" 
TheList.list.selection = 57 
TheList.list.value = "57" 
TheList.list.selection = 58 
TheList.list.value = "58" 
TheList.list.selection = 59 
TheList.list.value = "59" 
TheList.list.selection = 60 
TheList.list.value = "60" 
TheList.list.selection = 61 
TheList.list.value = "61" 
TheList.list.selection = 62 
TheList.list.value = "62" 
TheList.list.selection = 63 
TheList.ilist.value = "63" 
TheList.list.selection = 64 
TheList.list.value = "64" 
TheList.list.selection = 65 
TheList.list.value = "65" 
TheList.list.selection = 66 
TheList.list.value = "66" 
TheList.list.selection = 67 
TheList.list.value = "67" 
TheList.list.selection = 68 
TheList.list.value = "68" 
TheList.list.selection = 69 
TheList.list.value = "69" 
TheList.list.selection = 70 
TheList.list.value = "70" 
TheList.list.selection = 71 
TheList.list.value = "71" 
TheList.list.selection = 72 
TheList.list.value = "72" 
TheLiet.list.selection = 73 
TheList.list.value = "73" 
TheList.list.selection = 74 
TheList.list.value = "74" 
TheList.list.selection = 75 
TheList.list.value = "75" 
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TheList.list.selection = 76 
TheList.list.value = "76" 
TheLiest.list.selection = 77 
TheList.list.value = "77" 
TheList.list.selection = 78 
TheList.list.value = "78" 
TheList.list.selection = 79 
TheList.list.value = "79" 
TheList.list.selection = 80 
TheList.list.value = "80" 
TheList.list.selection = 81 
TheList.list.value = "81" 
TheList.list.selection = 82 
TheList.list.value = "82" 
TheList.list.selection = 83 
TheList.list.value = "83" 
TheList.list.selection = 84 
TheList.list.value = "84" 
TheList.list.selection < 85 
TheList.list.value = "85" 
TheList.list.selection = 86 
TheList.list.value = "86" 
TheLiet.list.selection = 87 
TheList.list.value = "87" 
ThelList.list.selection = 88 
TheList.liet.value = "88" 
TheLisat.list.selection = 8&9 
TheList.list.value = "89" 
TheList.list.selection = 90 
TheList.list.value = "90" 
TheList.list.selection = 91 
TheList.list.value = "91" 
TheList.list.selection = 92 
TheList.list.value = "92" 
TheList.list.selection = 93 
TheLiet.list.value = "93" 
TheList.list.selection = 94 
TheList.list.value = "94" 
TheList.list.selection = 95 
TheList.list.value = "95" 
TheList.liset.selection = 96 
TheList.list.value = "96" 
TheList.list.selection = 97 
TheLiet.list.value = "97" 
TheList.list.selection = 98 
TheList.list.value = "98" 
TheList.list.selection = 99 
TheList.list.value = "99" 


endmethod 
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; Page 1: TICKET: :TheList: :arrive* 


COMMENT: LISTS POINTS AWARDED FOR TRAFFIC VIOLATIONS 
IN THE POINTS FIBRLD ON THE TICKET INFORMATION 
SCREEN 


“ae "=a me 


method arrive(var eventInfo MoveEvent) 


jlists points awarded for traffic violations from 01-99 
jas shown below. the list is displayed in a drop down 
;eecroll box. 


TheList.list.selection = 1 
TheList.list.value = "01" 
TheList.list.selection = 2 
TheList.list.value = "02" 
TheList.list.selection = 3 
TheList.list.value = "03" 
TheList.list.selection = 4 
TheList.list.value = "04" 
TheList.list.selection = 5 
TheList.list.value = "05" 
TheList.list.selection = 6 
TheList.list.value = "06" 
TheList.list.selection = 7 
TheList.list.value = "07" 
TheList.list.selection = 8 
TheList.list.value = "08" 
TheList.list.selection = 9 
TheLiet.list.value = "09" 
TheList.list.selection = 10 
TheList.list.value = "10" 
‘TheList.list.selection = 11 
TheList.list.value = "11" 
TheList.list.selection = 12 
TheList.list.value = "12" 
TheList.list.selection = 13 
TheList.list.value = "13" 
heList.list.selection = 14 
TheList.list.value = "14" 
TheList.list.selection = 15 
TheList.list.value = "15" 
TheList.list.selection = 16 
heLiet.list.value = "16" 
TheList.list.selection = 17 
eList.list.value = "17" 
neList.list.selection = 18 
eList.list.value = "18" 
heList.list.selection = 19 
heList.list.value = "19" 
heList.list.selection = 20 
eList.list.value = "20" 
heList.list.selection = 21 
heList.list.value = "21° 
TheList.list.selection = 22 
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TheList.list.value = "22" 
TheList.list.selection = 23 
TheList.list.value = "23" 
TheList.liet.selection = 24 
TheList.list.value = "24" 
TheList.list.selection = 25 
TheList.list.value = "25" 
TheList.list.selection = 26 
TheList.list.value = "26" 
TheList.list.selection = 27 . 
TheList.list.value = "27" 
TheList.list.selection = 28 
TheList.list.value = "28" 
TheList.liet.selection = 29 
TheList.list.value = "29° 
TheList.liet.selection = 30 
TheList.list.value = "30* 
TheList.list.selection = 31 
TheList.list.value = "31" 
TheList.list.selection = 32 
TheList.list.value = "32" 
TheList.list.selection = 33 
TheList.list.value = "33" 
TheList.list.selection = 34 
TheList.list.value = "34° 
TheList.list.selection = 35 
TheList.list.value = "35" 
TheList.list.selection = 36 
TheList.list.value = "36" 
TheList.list.selection = 37 
TheList.list.value = "37" 
TheList.list.selection = 38 
TheList.list.value = "38" 
TheList.list.selection = 39 
TheList.list.value = "39" 
TheList.list.selection = 40 
TheList.list.value = *40" 
TheList.list.selection = 41 
TheList.list.value = "41" 
TheList.list.selection = 42 
TheList.list.value = "42" 
TheList.list.selection = 43 
TheList.list.value = "43" 
TheList.list.selection = 44 
TheList.list.value = "44" 
TheList.list.selection = 45 
TheList.list.value = "45" 
TheList.list.selection = 46 
TheList.list.value = "46" 
TheList.list.selection = 47 
TheList.list.value = "47" 
TheList.list.selection = 48 
TheList.list.value = "48" 
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TheList.list.selection = 49 
TheList.list.value = "49" 
TheList.list.selection = 50 
TheList.list.value = "50" 
TheList.list.selection = 51 
TheList.list.value = "51" 
TheList.list.selection = 52 
TheList.list.value = "52" 
TheList.list.selection = 53 
TheList.list.value = "53" 
TheList.list.selection = 54 
TheList.list.value = "54" 
TheList.list.selection = 55 
TheList.list.value = "55" 
TheList.list.selection = 56 
TheList.list.value = "56" 
TheLiet.list.selection = 57 
TheList.list.value = "57" 
TheList.list.selection = 58 
TheList.lisat.value = "58" 
TheList.list.selection = 59 
TheList.list.value = "59" 
TheList.list.selection = 60 
TheLiet.list.value = "60" 
TheList.list.selection = 61 
TheList.list.value = "61" 
TheList.list.selection = 62 
TheList.list.value = "62" 
TheList.list.selection = 63 
TheList.list.value = "63" 
TheList.list.selection = 64 
TheList.list.value = "64" 
TheList.list.selection = 65 
TheList.list.value = "65" 
TheList.list.selection = 66 
TheList.list.value = "66" 
eList.list.selection = 67 
TheList.list.value = "67" 
TheList.list.selection = 68 
TheList.list.value = "68" 
TheList.list.selection = 69 
eList.list.value = "69" 
heList.list.selection = 70 
eList.list.value = "70" 
heList.list.selection = 71 
eList.list.value = "71" 
heList.list.selection = 72 
eList.list.value = "72" 
eList.list.selection = 73 
heList.list.value = "73" 
heList.list.selection = 74 
eList.list.value = "74" 
eList.list.selection = 75 
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TheList.list.value = "75" 
TheList.list.selection = 76 
TheList.list.value = "76" 
TheList.list.selection = 77 
TheList.list.value = "77" 
TheList.list.selection = 78 
TheList.list.value = "78" 
TheLiest.list.selection = 79 
TheList.list.value = "79" 
TheList.list.eelection = 80 
TheList.list.value = "80" 
TheList.list.selection = 81 
TheList.list.value = "81" 
TheList.list.selection = 82 
TheList.list.value = "82" 
TheList.list.selection = 83 
TheList.list.value = "83" 
TheList.list.selection = 84 
TheList.list.value = "84" 
TheList.list.selection = 85 
TheList.list.value = "85" 
TheList.list.selection = 86 
TheList.list.value = "86" 
TheList.list.selection = 87 
TheList.list.value = "87* 
TheList.list.selection = 88 
TheList.list.value = "88" 
TheList.list.selection = 89 
TheList.list.value = "89" 
TheList.list.selection = 90 
TheList.list.value = "90" 
TheList.list.selection = 91 
TheList.list.value = "91" 
TheList.list.selection = 92 
TheList.list.value = "92°" 
TheList.list.selection = 93 
TheLiest.list.value = "93" 
TheList.list.selection = 94 
TheList.list.value = "94" 
TheList.list.selection = 95 
TheList.liet.value = "95" 
TheList.list.selection = 96 
TheList.liet.value = "96" 
TheList.list.selection = 97 
TheList.list.value = "97" 
TheList.list.selection = 98 
TheList.list.value = "98" 
TheList.list.selection = 99 
TheList.list.value = "99" 


endmethod 
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; COMMENT: ADVANCES LEVRAS REPORTS FORM TO CUSTOM 
7; TEMPORARY SUSPENSION OF DRIVING PRIVILEGES REPORT 


method pushButton(var eventInfo Event) 
;declares Custom report 
var 


custRptReport 
endVar 


custRpt.open ("Custom") 


endmethod 


Page 1: 8B:\REPORTS: : #Button®8: :pushButton* 


;COMMENT: ADVANCES LEVRAS REPORTS FORM TO CUSTOMER 
; VEHICLE (S) REPORT 


method pushButton(var eventInfo Event) 
;declares vehicle report 
var 
vehiRptReport 
endVar 
;g8ee comment above 
vehikpt.open("Vehicle") 


endmethod 
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Page 1: 8B:\REPORTS: :#Button10: :pushButton* 


;COMMENT: ADVANCES LEVRAS REPORTS FORM TO CUSTOMER 
7DECAL REPORT 


method pushButton(var eventInfo Event) 
;declares Decal Report 
var 
decaRptReport 
endVar 
;8ee comment above 


decaRpt . open ("Decal") 


endmethod 


Page 1: B:\REPORTS: : #Button12: :pushButton* 


;COMMENT: ADVANCES LEVRAS REPORTS FORM TO NAVAL 
;NAVAL POSTGRADUATE TICKET VIOLATION REPORT 


method pushButton(var eventiInfo Event) 
ideclares Ticket report 
var 
tickRptReport 
endVar 
;see comment above 


tickRpt.open("ticket") 


endmethod 
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APPENDIX J. LEVRAS USER'S MANUAL 


This appendix contains instructions on how to use the Law Enforcement and Vehicle 
Administration Registration System. The following pages are designed to be a ready reference 
manual for user's that need additional LEVRAS knowledge. A copy of Appendix J will be 
provided to the Naval Postgraduate School Security Department during system installation. 


167 








THE NAVAL POSTGRADUATE SCHOOL 
SECURITY DEPARTMENT 


THE LAW ENFORCEMENT AND VEHICLE REGISTRATION 
ADMINISTRATION SYSTEM (LEVRAS) 


DESIGNERS 
CDR MARK S. NAULT 
LT HENRY M. MCGIBBON 


MONTEREY, CALIFORNIA 
SEPTEMBER 1995 






— 
AEUNNENNTE 


168 











TABLE OF CONTENTS 


7. e¢ = ee © = = 8 © © © 8 & © © © © © © BF e eS FS Ff — FF Fw F © © BP e Be ee Be Oe we ee © © © © © © © ws © © © 8 © & ww Bw @ 


1.1 - Purpose of the User's Manual ..............0. 00.000 000 cee eee eee 1 
Lo = Poms OF COMtact 23. c.tuvev cscs hasta ikes eodhoswaenceasedes ender 1 
1.3 - Software Development ..........0...0.0 000 ccc cece cece ene eae Z 
LA DeNVGrADleS:- acer tasks twee wad bbe es pane oh adaeeees 2 
LS 2DISKetle PICS IG esx cig oats tenchuinarataa-en shies Gas wee eis Sate ease bak 2 
HE. DVO PEMEINFORMA TION... csveeg ocean teeeestedese tate beng dwasw 5 
2.1 - Hardware/Software Requirements ..........0..000 00.0... 0. ccc cee eee 5 
2.2 = Instatling LEVRAS.. gis23 6s5s de0eeacve sy Xaean Soba eine ee eee eau. 5 
2.3 - System Callup/Passwords ............0. 0000. c ce cece cece cece eee ees 5 
2.4 - Log-Out and Power-down Procedures .......... 00.0000. e cece eee 6 
Zo SOUSEKCCOING: tvccdcncd Gentes Meme eet easy ak eed cee Ae 6 
2.0: EirOr, MeSSagG. 25.4:) 4b cache ene ehwicnaee Ged eohdes ob eee ahd eens bs 7 
lll. DETAILED PROGRAM DESCRIPTION .........0 000.0... 00 cece eee eee 8 
3.1 - Tutorial for Welcome Screen ............0 0.00. c eee eee ee eee 8 
3.2 - Tutorial for Main Menu ...............0 000 cece ccc eee eee nes 8 
3.3 - Tutorial for Customer Data Processing ..............0 0.0... cee eee 9 
3.4 - Tutorial for Driver License Data Processing ....................0000- 9 
3.5 - Tutorial for Insurance Data Processing ............... 0.00.00. 000- 10 
3.6 - Tutorial for Registration Data Processing .....................000. 10 
3.7 - Tutorial for Vehicle Data Processing ...................0.0 0c eee 10 


169 





3.8 - Tutorial for Decal Data Processing ................... een tediaas 10 


3.9 - Tutorial for Ticket Data Processing ......... 00... 0.00. c eee eee 10 
3.10 - Tutorial for Ticket Administration ..................00.0. 0.05000. 1] 
3.11 - Tutorial for Displaying and Printing Reports ...............0..000.. 11 
3.12 - Tutorial for Archive Data Processing .............0...00......0000. 11 
TV EVRA CODES oe secesesuatarmadecd rit oe disa eee ca Gime or 
4.1 - State and Country Codes .......0 0.0.0... es 13 
42 DeCal Color COdES iano eee eae e SE Po ch ERS Seo baer koa ou 14 
4.3 -Employee Type Codes .........0.0 0.000.000 cece eee eens 14 
Bi ec J 16 [oicid O68 (1. a a re ee ee re 15 
RAI OC on. Serge bse ee hen eee eee Ga a eee 15 
4.6 - Ticket Violation Codes .........0.0 0.0000 ccc cece cece eee eens 15 
V. USER'S MANUAL REFERENCES .......0..0.000 0000000 c ccc cece eee es 19 


170 








I. GENERAL 


1.1 Purpose of the User's Manual. This manual is to provide users of the Law 
Enforcement and Vehicle Registration Administration System (LEVRAS) with the necessary 
information required to operate its program. After review of this manual, the user will have 
the required knowledge to add, modify, delete, query and print vehicle registration and ticket 
information with regards to a vehicle registration customer at the Naval Postgraduate 
School, Monterey, California. The LEVRAS User's Manual will assume that the user has 
no previous knowledge of the LEVRAS program. Thus, this manual will become a valuable 


resource/training aid for all LEVRAS program users. 


1.2 Points of Contact. All questions/concerns pertaining to LEVRAS will be forwarded 
to the individuals listed below (address of the LEVRAS designers remains current until - 


September, 1995): 


Superintendent, Code 370 

Naval Postgraduate School 

Monterey, CA 93943-5000 
(408) 656-2536 


Attention: LEVRAS Designers 
CDR M. S. Nault 
LT H. M. McGibbon 


After September 1995, contact the Naval Postgraduate School's Management Information 
System (MIS) Office at (408) 656-2195. The MIS office is located in Herrmann Hall room 
E-204. For specific LEVRAS related questions, contact the Computer Specialist, Renee A. 


Lightcap or successor at extension 1066 (e-mail address: rlightcap@nps.navy.mil). 
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1.3 Software Development. The LEVRAS system program was developed by two Naval 
Postgraduate students: CDR Mark S. Nault and LT Henry M. McGibbon for their 
Information Technology Management (ITM) thesis. SALSA (a semantic object modeling 
methodology tool) by Wall Data, Incorporated and Paradox, version 4.5 for Windows (a 
relational database language) by Borland International, Incorporated were extensively used 
for the LEVRAS program design and development. The LEVRAS system application 
program and documentation are the exclusive property of the Naval Postgraduate School and 
the U.S. Navy. 


1.4 Deliverables. The deliverables for the LEVRAS program include: 


a. One (1) 3.5 floppy diskette containing the LEVRAS Program. 
b. One (1) LEVRAS Users Manual. 


Note: Saved code generation data files (*.SSL, *.FSL and *.RSL) will be retained by the 
_ NPS Security Officer for back-up purposes. 


1.5 Diskette Files List. The 68 LEVRAS files listed below, when interfaced with Paradox, 
will enable the user to operate LEVRAS program. 





What makes that LEVRAS operate? 
Files...and more files! 
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fon 
ARCHIVE.DB 
ARCHIVE.FDL 
ARCHIVE.PX 
ARCHIVE.QBE 
ARCHIVE. VAL 
BEGIN.SDL 
CUSTOM. RSL 
CUSTOMER. FDL 
CUSTOMER.OQBE 
DECAL.FDL 
DECAL.RDL 
DRIVERLL VAL 
DVRLISEN.FDL 
GEMSETUP.DB 
GEMSETUP.TXT 
INSURANC.FDL 
MAINMENU FDL 
PDOXWORK. INI 
PROCESST.FDL 
REGISTER.FDL 
REPORTS.FDL 
TICKET FDL 
TICKET.RDL 
VEHICLE.FDL 
VEHICLE.RDL 
WELCOME:FDL 


Refer to the following page for the LEVRAS file listing. 
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\SALSA\ 
CUSTOMER.DB 
CUSTOMER.PX 
CUSTOMER. VAL 
DECAL.DB 
DECAL.PX 
DECAL. VAL 
DECAL.X06 
DECAL.XO7 
DECAL. YO6 
DECAL. YO7 
DRIVERLLDB 
DRIVERLLPX 
DRIVERLL VAL 
DRIVERLLX04 
DRIVERLL YO4 
INSURANC.DB 
INSURANC.PX 
INSURANC.VAL 
INSURANC.X04 
INSURANC.XO5 
INSURANCE. YO4 
INSURANCE. YO5 
REGISTRA.DB 
REGISTRA PX 
REGISTRA. VAL 
REGISTRA.X04 
REGISTRA.XO5 
REGISTRA.YO4 
REGISTRA. YOS 
TICKET.DB 
TICKET.PX 
TICKET. VAL 
TICKET.XOB 
TICKET.XOC 
TICKET. YOB 
TICKET. YOC 
USAENGL RSL 
VEHICLE.DB 
VEHICLE.PX 
VEHICLE. VAL 
VEHICLE.XO8 
VEHICLE. YO8 


Extension 


* DB 
* FDL 
* FSL 
* FTL 
* INI 
* PX 
* OBE 
* RDL 
* RSL 
* SDL 
* SSL 
* VAL 
* XOn 
* YOn 


The LEVRAS file extensions are correlated to their respective file types: 


Type of File 


Table 

Delivered Form 

Saved Form 

Temporary Form 

Initializing Configuration File 

Primary Index of File 

Saved Query 

Delivered Report 

Saved Report 

Delivered Script 

Saved Script 

Validity Table Check 

Secondary Single-Field Index for a Table 
Secondary Single-Field Index for a Table 
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If. SYSTEM INFORMATION 


2.1 Hardware/Software Requirements. The following microcomputer hardware 
configuration should support the minimum requirements for using the LEVRAS software 
program (assuming that the user does not have a LEVRAS Information System): a) An IBM 
compatible 386, 25 MHZ, microcomputer with a 3.5" floppy disk drive and at least 4 MB 
of RAM and 22 MB free hard disk space (for both Paradox software and LEVRAS program 
files). b) Microsoft Windows (version 3.1 or higher). c) A 132-character width printer 
that uses the standard 8.5" x 11" paper. d) A mouse. e) An VGA or higher video card. 


2.2 Installing LEVRAS. Power up your microcomputer using normal power up 
procedures. Start Windows and choose File Manager. Create a C:\SALSA directory: Using 
File Manager copy B:\ files to the C:\ directory. Also, copy the B:\SALSA files to the 
CASALSA directory. Exit File Manager. Start Paradox for Windows. Your microcomputer 
is now ready to callup the LEVRAS program. | 

To prevent loss of LEVRAS program files, it is strongly recommended that you make 
a backup of all LEVRAS files onto another 3.5" diskette. One diskette will be the master 
and the other a working copy. From the DOS C:\> prompt, copy all LEVRAS files by 
typing, "DISKCOPY A: A:" (a: is assumed as the 3.5" floppy drive, if b: is the 3.5" disk 
drive, use b: in lieu of a:). Insert the LEVRAS SOURCE diskette into drive A. Push the 
return key. After your microcomputer prompts you to insert the target diskette, remove the 
LEVRAS source diskette and insert the target diskette. When prompted, name your volume 
label: WORKINGCOPY. Now you have a LEVRAS program master and working copy. 


2.3 System Callup/Passwords. Once the LEVRAS system software is installed, callup the 
LEVRAS program by clicking on the SCRIPT pushbutton (located on the speedbar). Select 
BEGIN.SDL and click on OK. The "ABOUT LEVRAS" dialogue box will appear and when 
finished reading the box contents, click on OK. The Welcome screen will appear (where 


you will see two handsome LEVRAS designers). Press start to begin the LEVRAS program. 
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The LEVRAS program software is password protected (in compliance with the 
Privacy Act Law of 1974); therefore, when prompted at the "PASSWORD" dialogue box for 
the system password, type> POLO (be aware, Paradox passwords are case sensitive and 
would not normally be disclosed in a user's manual). Each table in LEVRAS is password 
protected; however, you need only type the password once to get into the LEVRAS program 
when prompted for the password in the PASSWORD Window. If successful at entering in 
the correct password, all system screens will become fully functional. For further 
instructions on the LEVRAS program, refer to the DETAILED PROGRAM DESCRIPTION 
in Part III of this manual. | 

To change the LEVRAS password (which is recommended on a routine basis) select 
File -> Utilities -> Restructure (select the first table), under Table Properties scroll to 
Password Security and select Modify. Type in the new password and click OK then Verify 
and Save. To test the new LEVRAS password, exit Paradox. Restart Paradox to activate 
the new Password. Repeat the procedure above to change all system table passwords. It is 


recommended that the same password be used for each table (*.DB file). 


2.4 Log-out and Power-down Procedures. To log-out of the LEVRAS program, you must 
be in the "Main Menu" window. Once there, click on the EXIT pushbutton. This action will 
exit you out of the LEVRAS program altogether . To exit Paradox select File, then Exit. 
Follow the normal procedures to exit MicroSoft Windows completely (refer to MicroSoft 
Windows User's Manual). To power-down the microcomputer, refer to the local SOP 


instructions or your hardware user's manual. 


2.5 Housekeeping. LEVRAS is intended to retain a large amount of information that 
pertains to Naval Postgraduate School (NPS) affiliated customers that register their vehicles 
at the NPS Vehicle Registration Office. Since there is a substantial amount of information, 


it is strongly recommended that the user periodically save his/her data at intervals that would 


176 








require no more than one half-hour worth of work to reconstruct, if temporary loss of power 


or some other mishap should occur. 


2.6 Error Message. If LEVRAS should produce an error message during program 
operation, a number of user and/or computer software related problems might have occurred. 
The user should discontinue the activity that is causing the error and save data that has been 
previously processed before continuing on with any further computer related process. 
Numerous Message stop dialogue boxes and status line messages have been programmed 


in the LEVRAS computer code to assist the user if an error should occur. 
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il. DETAILED PROGRAM DESCRIPTION 


3.1 Tutorial for Welcome Screen. The Welcome Screen is called, "Welcome to the Law 
Enforcement Vehicle Registration and Administration System". The Welcome screen has 
one pushbutton (and two smiling faces). Click on the Start pushbutton to commence the 
LEVRAS program. 


3.2 Tutorial for Main Menu. The Main Menu has seven pushbuttons (CUSTOMER 
DATA, PROCESS TICKET, QUERIES, REPORTS, ARCHIVE, HELP, and EXIT). 


p CUSTOMER DATA: Clicking on this pushbutton takes the user to the Customer 
Information form for data insertion. The remaining data entry forms follow the 
Customer Information form to make a complete customer record. 

pb PROCESS TICKET: Clicking on this pushbutton takes the user to the Process 
Ticket Information form, which is used by the NPS Ticket Administrator. This 
screen is normally used when a complete customer record has been entered in by the 
Vehicle Registration Administrator. 

b QUERIES: Clicking on this pushbutton provides instructions on how to perform a 
Customer.qbe (query) via a dialog box. The dialog box specifically states how to 
perform a query. When the "Select File Box" appears, choose the desired query 
(*.qbe file). After you choose the desired query file, place a check on the desired 
fields by clicking on the box next to field name. For specifics on the powerful 
Paradox query capabilities refer to page 323, table 16-2 of the Guide to ObjectPal 
Paradox 4.5 for Windows software literature. 

pb REPORTS: Clicking on this pushbutton takes the user to the LEVRAS Reports 
Menu, to select one of the four output reports. 

pb ARCHIVE: Clicking on this pushbutton takes the user to the Archive Information 
form to allow archive data entry and queries. 


) HELP: Clicking on this pushbutton takes the user to the LEVRAS Help dialog box. 
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b EXIT: Clicking on this pushbutton takes the user out of the LEVRAS program and 


into the generic Paradox startup screen. 


3.3 Tutorial for Customer Data Processing. This form has six pushbuttons (ADD, 
MODIFY, DELETE, FWD, HOME, and HELP). Each of these pushbuttons are self- 
explanatory; however, use the F9 key on your keyboard to get into edit mode (if prompted). 
To enter a new customer into the LEVRAS database, click on the ADD pushbutton and start 
entering in the fields. In the SSN field dashes will automatically appear to separate the 
social security numbers, and only numbers can be entered. All fields that require letters or 
alphanumeric data entries will capitalize the letters automatically. Scroll box fields require 
the user to either enter in their own data or use the scroll box information (to maintain a 
standard database, the designers recommend using the scroll box information). the phone 
number fields require that the user first push the spacebar on their keyboard to produce the 
open parenthesis bracket for the area code. The other area code parenthetical bracket and 
dash will automatically appear without any user intervention. The SMC#, Curric/Staff and 
Faculty fields require no data or the appropriate number of data characters to completely fill 
the fields. The Database Entry Date field requires the following format MM/DD/YY. The 
month and day data elements require a zero in front of a single number month or day (for 
example, April will require the user enter 04). 

For CUSTOMER INFORMATION form fields that request for "Home State, 
Employee Type, Rank, Sex, and Grade" refer to Part IV - LEVRAS CODES of this User's 
Manual. To delete customer information, push the delete button (data entered on other 
forms will not be affected). To enter other vehicle registration information press FWD 
(takes you to the Driver License Information form) or press HOME (takes you back to the 
Main Menu). 


3.4 Tutorial for Driver License Data Processing. The data entry procedures for this form 
are similar to the Customer Information form. Ensure that the social security number (SSN 


field) matches the Customer Information form data. To go back to the Customer 
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Information form press BACK. To go forward to the Insurance Information form press 
FWD. 


3.5 Tutorial for Insurance Data Processing. The data entry procedures for this form are 
similar to the Customer Information form. Ensure that the social security number (SSN 
field) matches the Customer Information form data. To go back to the Driver License 
Information form press BACK. To go forward to the Registration Information form press 
FWD. 


3.6 Tutorial for Registration Data Processing. The data entry procedures for this form 
are similar to the Customer Information form. Ensure that the social security number (SSN 
field) matches the Customer Information form data. To go back to the Insurance 
Information form press BACK. To go forward to the Vehicular Information form press 
FWD. 


3.7 Tutorial for Vehicle Data Processing. The data entry procedures for this form are 
similar to the Customer Information form. Ensure that the social security number (SSN 
field) matches the Customer Information form data. Additional scroll box fields, which 
operate similar to the Customer Information scroll box fields are: Vehicle Year, Vehicle 
Make, and Vehicle Color. To go back to the Registration Information form press BACK. 


To g0 forward to the Decal Information form press FWD. 


3.8 Tutorial for Decal Data Processing. The data entry procedures for this form are 
similar to the Customer Information form. Ensure that the social security number (SSN 
field) matches the Customer Information form data. Additional scroll box fields, which 
operate similar to the Customer Information scroll box fields are: Decal Color, Decal 
Expiration Date, and Decal Expiration Year. To go back to the Vehicular Information form 


press BACK. To go forward to the Ticket Information form press FWD. 
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3.9 Tutorial for Ticket Data Processing. The data entry procedures for this form are 
similar to the Customer Information form. Ensure that the social security number (SSN 
field) matches the Customer Information form data. Additional scroll box fields, which 
operate similar to the Customer Information scroll box fields are Violation Code and Points. 
To go back to the Decal Information form press BACK. To go forward to the Process Ticket 
Information form press PROC TKT. 


3.10 Tutorial for Ticket Administration. This form was intended for the Ticket 
Administrator. Basically, it provides an all encompassing view of a customer and any 
tickets. It should be used to locate a customer, and update the ticket status (for information 
that was previously entered on the other data forms). To get the most out of this form, first 
locate a record that needs a ticket be updated by pushing the LOCATE pushbutton.: Follow 
the instructions in the LOCATE dialog box to locate the intended customer record. The 
other pushbuttons operate similar to the Customer Information form. The Decal, Vehicle, 
and Ticket scroll boxes can be modified by pressing the MODIFY pushbutton or press F9 
on the computer keyboard to edit. Press FWD to return to the Ticket Information form. 


Press HOME to return to the Main Menu. 


3.11 Tutorial for Displaying and Printing Reports. The LEVRAS Reports menu lists 
four types of reports: CUST/VEH (Customer/Vehicle), DECAL, TICKET, and CUSTOM. 
Upon selection of a particular report, the report will display one customer record. The user 
can use the speedbar to locate a particular record (see Ticket Administration, Section 3.10) 
or scroll through each record. To leave a called up report, go to the upper left corner of the 
report window and choose Close. The CUST/VEH report displays a customer and his or her 
vehicles. The DECAL report displays a customer and his or her decals. The TICKET report 
displays a customer with his or her decals, vehicles, and tickets. The CUSTOM report 
displays a temporary suspension of driving privileges memo from the NPS Security Officer. 
This report may be customized by pressing the design pushbutton on the report speedbar. 
Then manipulate the report as required. Press the lightning bolt pushbutton when done 
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editing the CUSTOM report. To leave the LEVRAS Report menu press the HOME 


pushbutton to return to the Main Menu. 


3.12 Tutorial for Archive Data Processing, The data entry procedures for this form are 
similar to the Customer Information form. Ensure that the social security number (SSN 
field) matches the Customer Information form data. Scroll box fields, which operate similar 
to other data entry form scroll box fields are: Vehicle Year, Vehicle Make, Vehicle Color, 
License Plate State, and Decal Color. Archive queries are similar to the active database 
Customer queries discussed in Section 3.2 with the exception of the selection of Archive.qbe 


file for these queries. To go back to the Main Menu press HOME. 











IV. LEVRAS CODES 


4.1 State and Country Codes. The following codes are used in the fields that require a 


state/country within the respective INFORMATION forms are listed below: 


AL: Alabama 
AK: Alaska 

AR: Arkansas 
AS: American Samoa 
AZ: Arizona 
BG: Belgium 
CA: California 
CN: Canada 
CO: Colorado 
CT: Connecticut 
CZ: Canal Zone 
DC: District of Columbia 
DE: Delaware 
DM: Denmark 
FL: Florida 

FR: France 

GA: Georgia 
GM: Germany 
GR: Greece 

GU: Guam 

HI: Hawaii 

IA: Iowa 

IC: Iceland 

ID: Idaho 

IL: Illinois 

IN: Indiana 

IT: Italy 

KY: Kentucky 
KS: Kansas 

LA: Louisiana 
LX: Luxembourg 
MA: Massachusetts 
MD: Maryland 
ME: Maine 

MI: Michigan 
MN: Minnesota 


MO: Missouri 

MS: Mississippi 
MT: Montana 

NC: North Carolina 
ND: North Dakota 
NE: Nebraska 

NH: New Hampshire 
NJ: New Jersey 
NL: Netherlands 
NM: New Mexico 
NV: Nevada 

NW: Norway 

NY: New York 
OH: Ohio 

OK: Oklahoma 
OR: Oregon 

PA: Pennsylvania 
PR: Puerto Rico 
PT: Portugal 

RI: Rhode Island 
SC: South Carolina 
SD: South Dakota 
TN: Tennessee 
TK: Turkey 

TT: Trust Territories 
TX: Texas 

VI: Virgin Islands 
UK: United Kingdom 
UT: Utah 

VA: Virginia 

VT: Vermont 

WA: Washington 
WI: Wisconsin 
WV: West Virginia 
WY: Wyoming 
XX: Others 
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4.2 Decal Color Codes. The following decal colors distinguish between the categories 
of a customer's job related positional status and should be entered in the "Decal Color" 


field on the respective INFORMATION forms as listed below: 


Blue: Officer 
Black: Commercial 
Green: Civilian 
Red: Enlisted 
White: Temporary 


4.3 Employee Type Codes. Employee types are used in the Employee Type field on the 
respective INFORMATION forms. Fill-in the appropriate Employee Type by entering in 


one of the following codes: 


CO: company 

ACDU: active duty military 
MILRES: military reservist 
RETMIL: retired military 
CIVGOV: civilian government 
COMMERCIAL: commercial 
MILDEP: military dependent 
DISVET: disabled veteran 


4.4 Grade Codes. Select one alphanumeric code which determines a customer's grade 


(civilian) on the respective INFORMATION forms as listed below: 


AS1 - AS7 Admin Support 

El - E9 Enlisted 

GM13 - GM15 Merit Pay System 

GS1 - GSI8 General Schedule 

NAI - NAIS5 Non-supervisory 

NLI - NLIS5 Leader 

PS1 = - PS7 Patron Service 

SES1 - SES9 Senior Executive Service 


WD1 - WD19 Production 
WG1 - WGI15S Wage Grade 
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WL1 - WLIS5 Leader 

WP1 - WP78 Printing 

WSI1 - WS19 Supervisor 

WT1 - WT12 Apprentice 

WT13 - WT18 Shop Trainee 

YV - YV3506 Summer Employee 
YW - YW3506 Winter Employee 
ZZ Other 


4.5 Rank Codes. Select one alphanumeric code which determines a customer's rank 


(military) on the respective INFORMATION forms as listed below: 


El -E-9 Enlisted Rank 
W1 -W5 Warrant Officer Rank 
O1 -O10 Officer Rank 


4.6 Ticket Violation Codes. The following ticket violation codes are used on the respective 
INFORMATION forms. Place the appropriate two digit code in the Violation Code field 


in lieu of the "Meaning" phrases: 


CODE MEANING 


0] Illegal Parking 

02 Speeding 

03 Expired/mutilated DECAL 

04 Improper equipment 

05 Blocking traffic 

06 No inspection sticker; rejected sticker; expired sticker 
07 Blocked railroad tracks (5 ft. fm tracks) 
08 Expired state license 

09 Reckless driving 

10 Hit and run 

11 Abandoned vehicle 

12 Failure to obey yield sign 

13 Failure to keep right 

14 Improper turn 

15 Failure to obey traffic light 

16 Failure to obey posted sign 








CODE MEANING 


17 
18 
19 
20 
2] 
22 
23 
24 
25 
26 
27 
28 
29 
30 
31 
32 
33 
34 
35 
36 
37 


Illegal traveling or being in a restricted area 
Traveling through a "NO THOROUGHFARE" 
Iilegal U-Turn 

Failure to have vehicle under control 

Driving while intoxicated (alcohol or drugs) 
No vehicle registration 

Child left unattended in vehicle 

Failure to obey stop sign 

Failure to obey traffic officer's signal 

Drag racing 

Following too close 

Illegal use of license plates 

Improper passing 

Improper backing 

Failure to obey aircraft warning lights 
Improper driving 

Leaving the scene of an accident 

Failure to give proper signal 

Operating vehicle on-base during a suspension 
Failure to yield to pedestrians in a crosswalk 
Impeding the flow of traffic 

Improper use of traffic lanes 

Failure to yield to emergency vehicle 

Unsafe vehicle 

Leaving vehicle unattended 

Allowing unlicensed person to operate vehicle 
Illegal use of visitor's pass 

High flagging 

Operating motorcycle without helmet or safety glasses 
Improper towing of vehicle 

Operating vehicle without license plates 
Operating loaded truck w/o material properly secured 
Using vehicle in commission of crime 
Refusal to allow breath/blood test 

No insurance 

Unnecessary noise 

Driving on revoked license 

Not having a valid operating license 
Operating vehicle underage (16 years old) 
Operating vehicle without lights in the dark 
Littering 
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CODE MEANING 


58 
59 
60 
61 
62 
63 
64 
65 
66 
67 


68 
69 
70 
71 
72 
73 
74 
75 
16 
77 
78 
79 
80 
81 
82 


83 
84 


85 
86 


Overloading vehicle 

Illegal display of base decal 

Illegal display of state license plates 

No base pass or decal 

Violating conditions of restricted privilege 
Manslaughter/Negligent homicide by op of vehicle 
Incompetent to op vehicle when physically impaired 
Unauth use of vehicle belonging to another (nofelony) 
Mandatory recovation is req upon conviction 
Offense in another state; suspension or recovation 
would have been required if occurring on base 
Attempting to elude police officer 

Violation of curfew laws 

Owner permitting another to operate vehicle when 
physically impaired 
Driving vehicle while impaired (alcohol level more 
than .05% and less than .10%) 

Failure to stop for school bus or school crossing signal 
Failure to yield (no official sign involved) 

Driver involved in an accident deemed responsible 
(add to specific offense) 

Operating motorcycle without helmet chinstrap 
fastened 

Operating motorcycle without headlights and/or 
taillights 

Operating motorcycle on sidewalk, lawn, seeded areas 
or other areas 

Perjury or making false affidavit or statement under 
oath 

Selling or disposing of vehicle with Naval Base Sticker 
Illegal use of decal issued to another person 
Permitting an unlawful or fraudulent use of an official's 
driver's license 

Failure to submit a written accident report when 
required by regulation and/or law 

Failure to maintain current registration record 
Repair of vehicle (non-emergency) on roadways, 
streets, parking areas/spaces 

Failure to register vehicle with police department 
Picking up or discharging passengers in other than 
designated areas 
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CODE MEANING 


87 
88 


89 


90 
91 


a2 
93 
94 
95 
96 
97 
98 
99 


Infraction of trfc codes or regulations not provided for 
Lending vehicle without giving borrower written 
permission and/or registration 

Driving anothers vehicle without written permission 
or registration 

Carpool violations 

Use of subterfuge to gain selective parking in carpool 
program 

Unauthorized use of decal issued for military purpose 
Violation of U.S. criminal codes 

Controlled substance 

Weapons violation 

Selling vehicle and not removing decal 

Jaywalking 

For future use 

For future use 
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V. USER'S MANUAL REFERENCES 


For further Paradox information, the designers of LEVRAS recommend the 
following publications: 


Borland International, Inc. Borland Paradox for Windows User's Guide, Scotts 
Valley: Borland International, Inc., 1992. 


Borland International, Inc. Guide to ObjectPAL, Scotts Valley: Borland 
International, Inc., 1992. 


Rock, James A. Teach Yourself Paradox for Windows in 21 Days. Carmel: 
Sams Publishing, 1993. 
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